В основу какой модели баз данных легли работы экодда?

11 ответов на вопрос “В основу какой модели баз данных легли работы экодда?”

  1. M!Dya Ответить

    61. Основой практически любой ИС является
    • Delphi
    • язык программирования высокого уровня
    • набор методов и средств создания ИС
    • СУБД
    62. К основным функциям, выполняемым СУБД, обычно относят
    • выполнение вычислений
    • протоколирование
    • построение диаграмм
    • управление транзакциями
    63. Поддержка механизма транзакций СУБД является
    • желательной
    • не обязательной
    • обязательной
    • весьма вероятной
    64. Параллельное выполнение смеси транзакций, результат которого эквивалентен результату их последовательного выполнения, называется
    • распараллеливанием
    • комплексной обработкой
    • сериализацией
    • одновременной обработкой транзакций
    65. Запись в журнале информации о изменениях происходящих в базе данных называется
    • протоколированием
    • учётом событий
    • фиксацией изменений
    • мониторингом
    66. Благодаря работам Э. Кодда были созданы базы данных
    • сетевые
    • иерархические
    • объектно-ориентированные
    • реляционные
    67. Реляционные базы данных получили своё название благодаря тому, что
    • таблицы данных связаны между собой
    • в них быстро обрабатывается информация
    • в них можно хранить данные сложной структуры
    • данные в них представлены в виде таблиц
    68. Последнее обновление стандарта языка SQL было принято в году
    • 1986
    • 1989
    • 1992
    • 1995
    69. Сущностям реального мира более близка модель данных
    • реляционная
    • иерархическая
    • сетевая
    • объектно-ориентированная
    70. В постреляционных СУБД используются модели данных
    • объектно-ориентированная и реляционная
    • реляционная и иерархическая
    • иерархическая и сетевая
    • причинно-обусловленная

  2. qwerty2712 Ответить

    БАЗА ДАННЫХ.
    ИНФОЛОГИЧЕСКАЯ МОДЕЛЬ БАЗЫ ДАННЫХ. ОСНОВНЫЕ ВИДЫ МОДЕЛЕЙ. ПРОЕКТИРОВАНИЕ
    БАЗ ДАННЫХ
    Основой базы данных
    является модель данных. Информационно-логическая (мифологическая) модель
    предметной области отражает предметную область в виде совокупности информационных
    объектов и их структурных связей.
    Информационный
    объект     — это описание некоторой сущности (явления, реального
    объекта, процесса) в виде совокупности логически связанных реквизитов.
    Например, информационный объект Студент описывает некоторую сущность —
    студент. Реквизитный состав этого информационного объекта, т. е. его структура,
    следующий: № группы, ФИО, № зачетной книжки, дата рождения. Информационный
    объект имеет множество реализаций — экземпляров.
    Базы данных также
    могут быть иерархическими, сетевыми и реляционными. Иерархическая
    (древовидная) модель данных     представляет собой иерархию
    элементов, называемых узлами. Узел — это совокупность атрибутов данных,
    описывающих информационный объект. На самом верхнем уровне имеется только
    один узел — корень. Каждый узел кроме корня связан только с одним узлом
    на более высоком уровне, называемом исходным узлом для данного узла. Каждый
    узел может быть связан с одним или несколькими узлами более низкого уровня,
    называемыми порожденными (подчиненными). Узлы, не имеющие порожденных,
    называются листьями. Количество деревьев в базе данных определяется числом
    корневых записей. К каждой записи базы данных существует только один путь.
    Сетевая
    модель     также основывается на понятиях узел, уровень, связь.
    Сетевая модель данных — это модель, в которой порожденный узел может иметь
    более одного исходного узла. В сетевой структуре любой элемент любого
    уровня может быть связан с любым другим элементом.
    Реляционная
    модель базы данных     состоит из одного или нескольких файлов,
    каждый из которых соответствует одной таблице.
    Основная цель проектирования
    базы данных — это сокращение избыточности хранимых данных, а следовательно,
    экономия объема используемой памяти, уменьшение затрат на многократные
    операции обновления избыточных копий и устранение возможности возникновения
    противоречий из-за хранения в разных местах сведений об одном и том же
    объекте. При создании баз данных следует придерживаться методологии нормализации
    отношений.
    Процесс проектирования
    информационных систем является достаточно сложной задачей. Он начинается
    с построения инфологической модели данных, т. е. идентификации сущностей.
    Затем необходимо выполнить следующие шаги процедуры проектирования даталогической
    модели, т. е. мифологическая модель должна быть ‘: отображена в компьютероориентированную
    даталогическую модель, «понятную» СУБД.
    Представить предметную
    область в виде совокупности отдельных независимых друг от друга
    объектов,
    каждый из которых будет описываться своей таблицей.
    Для каждой таблицы
    определить ключевые поля; установить связи между таблицами; для каждой
    связи определить тип.
    Разработать структуру
    каждой таблицы: перечень полей, их типы и свойства.
    Заполнить таблицы
    данными.
    Разработать необходимые
    запросы к БД, входные и выходные формы и отчеты.
    Предусмотреть
    возможность автоматизации часто выполняемых действий путем создания
    макросов и программных модулей.

  3. aN1232015 Ответить

    Некоторые структуры содержат циклы. Циклом считается ситуация, в которой предшественник узла является в то же время его последователем. Отношения «исходный — порожденный» образуют при этом замкнутый контур. Например, завод выпускает различную продукцию. Некоторые изделия производятся на других заводах-субподрядчиках. С одним контрактом может быть связано производство нескольких изделий. Представление этих отношений и образует цикл.
    Иногда объекты связаны с другими объектами того же типа. Такая ситуация называется петлей. На рис. 4 приведены две достаточно распространенные ситуации, где могут использоваться петли. В массиве служащих специфицированы связи, существующие между некоторыми служащими. В базу данных списка материалов введено дополнительное усложнение: некоторые узлы сами состоят из узлов.

    Разделение сетевых структур на простые и сложные необходимо потому, что сложные структуры требуют более сложных методов физического представления. Это не всегда является недостатком, поскольку сложную сетевую структуру можно (а в большинстве случаев и следует) преобразовать к простому виду.
    Использование иерархической и сетевой моделей ускоряет доступ к информации в базе данных. Но поскольку каждый элемент данных должен содержать ссылки на некоторые другие элементы, требуются значительные ресурсы как дисковой, так и основной памяти ЭВМ. Недостаток основной памяти, конечно, снижает скорость обработки данных. Кроме того, для таких моделей характерна сложность реализации системы управления базами данных (СУБД).

    2. Идентификация объектов и записей

    В задачах обработки информации атрибуты именуют (обозначают) и приписывают им значения.
    При обработке информации пользователь имеет дело с совокупностью объектов, информацию о свойствах каждого из которых надо сохранять (записывать) как данные, чтобы при решении задач их можно было найти и выполнить необходимые преобразования.
    Таким образом, любое состояние объекта характеризуется совокупностью атрибутов, имеющих некоторое из значений в этот момент времени. Атрибуты фиксируются на некотором материальном носителе в виде записи. Запись — совокупность (группа) формализованных элементов данных (значений атрибутов, представленных в том или ином формате). Значение атрибута идентифицирует объект, т.е. использование значения в качестве поискового признака позволяет реализовать простой критерий отбора по условию сравнения.
    Отдельный объект всегда уникален, поэтому запись, содержащая данные о нем, также должна иметь уникальный идентификатор, причем никакой другой объект не должен иметь такой же идентификатор. Поскольку идентификатор — суть значение элемента данных, в некоторых случаях для обеспечения уникальности требуется использовать более одного элемента. Например, для однозначной идентификации записей о дисциплинах учебного плана необходимо использовать элементы СЕМЕСТР и НАИМЕНОВАНИЕ ДИСЦИПЛИНЫ, так как возможно преподавание одной дисциплины в разных семестрах.
    Предложенная выше схема представляет атрибутивный способ идентификации содержания объекта. Она является достаточно естественной для хорошо структурированных (фактографических) данных. Причем, структурированность относится не только к форме представления данных (формат, способ хранения), но и к способу интерпретации значения пользователем (значение параметра не только представлено в предопределенной форме, но и обычно сопровождается указанием размерности величины, что позволяет пользователю понимать ее смысл без дополнительных комментариев). Таким образом, фактографические данные предполагают возможность их непосредственной интерпретации.
    Однако этот способ практически не подходит для идентификации слабо структурированной информации, связанной с объектами, имеющими идеальную природу. Такие объекты зачастую определяются логически и опосредованно — через другие объекты. Для их описания используются естественные или искусственные. Соответственно, для понимания смысла пользователю необходимо использовать соответствующие правила языка, и располагать некоторой информацией, позволяющей идентифицировать и связать получаемую информацию с наличным знанием. То есть процесс интерпретации такого рода данных имеет опосредованный характер и требует использования дополнительной информации, причем такой, которая не обязательно присутствует в формализованном виде в базе данных.

    3. Поиск записей

    Программисту или пользователю необходимо иметь возможность обращаться к отдельным, нужным ему записям или отдельным элементам данных.
    Для этого можно использовать следующие способы:
    – Задать машинный адрес данных и в соответствии с физическим форматом записи прочитать значение. Это случаи, когда программист должен быть «навигатором».
    – Сообщить системе имя записи или элемента данных, которые он хочет получить, и возможно, организацию набора данных. В этом случае система сама произведет выборку (по предыдущей схеме), но для этого она должна будет использовать вспомогательную информацию о структуре данных и организации набора. Такая информация по существу будет избыточной по отношению к объекту, однако общение с базой данных не будет требовать от пользователя знаний программиста.
    В качестве ключа, обеспечивающего доступ к записи, можно использовать идентификатор — отдельный элемент данных. Ключ, который идентифицирует запись единственным образом, называется первичным (главным).
    В том случае, когда ключ идентифицирует некоторую группу записей, имеющих определенное общее свойство, ключ называется вторичным (альтернативным). Набор данных может иметь несколько вторичных ключей, необходимость введения которых определяется требованием оптимизации процессов нахождения записей по соответствующему ключу.
    Иногда в качестве идентификатора используют составной сцепленный ключ — несколько элементов данных, которые в совокупности, например, обеспечат уникальность идентификации каждой записи набора данных.
    При этом ключ может храниться в составе записи или отдельно. Например, ключ для записей, имеющих неуникальные значения атрибутов, для устранения избыточности целесообразно хранить отдельно.
    Введенное понятие ключа является логическим и его не следует путать с физической реализацией ключа — индексом, обеспечивающим доступ к записям, соответствующим отдельным значениям ключа.
    Один из способов использования вторичного ключа в качестве входа — организация инвертированного списка, каждый вход которого содержит значение ключа вместе со списком идентификаторов соответствующих записей. Данные в индексе располагаются в возрастающем или убывающем порядке, поэтому алгоритм нахождения нужного значения довольно прост и эффективен, а после нахождения значения запись локализуется по указателю физического расположения. Недостатком индекса является то, что он занимает дополнительное пространство и его надо обновлять каждый раз, когда удаляется, обновляется или добавляется запись.
    В общем случае инвертированный список может быть построен для любого ключа, в том числе составного.
    В контексте задач поиска можно сказать, что существуют два основных способа организации данных: Первый способ представляет прямую организацию массива, второй — является инверсией первого. Прямая организация массива удобна для поиска по условию «Каковы свойства указанного объекта?», а инвертированная — для поиска по условию «Какие объекты обладают указанным свойством?».

  4. Vendatha Ответить

    вызова и исполнения триггеров (в частности, исполнение одного триггера может привести к срабатыванию другого) и б) неявности триггеров. Последнее соображение заключается в том, что триггеры представляют собой побочный эффект операций над таблицей и ее записями. Если же с операциями над записями какой-либо таблицы должна быть связана какая-либо дополнительная логика, ее реализуют в виде хранимых процедур, и принимают соглашения, что все действия с записями данной таблицы должны выполняться только через вызов этих хранимых процедур (принцип инкапсуляции, в применении к реляционным базам данных, реализуемый за счет соглашения).
    Объектно-ориентированные базы данных. Идея применить принципы объектно-ориентированного программирования, в частности, инкапсуляцию, к
    базам данных выглядит исключительно привлекательно, и предпринимались неоднократные попытки ее реализации; хороший анализ работ в этом направлении можно найти в гл. 1 и 2 в книге [10]. В [10] приводится детальное обсуждение причин, по которым основную часть проектов по реализации объектно/реляционных СУБД нельзя признать (удачным) решением указанной проблемы: они содержат концептуальные изъяны. Суммируя вкратце, таких основных изъянов два: а) отсутствие четкого понимания разницы между
    моделью и ее реализацией и б) неверное понимание концепции типа. Понятие
    тип является фундаментальным для всех компьютерных наук; неверное понимание этого понятия ведет не только к ошибкам в проектировании и реализации объектно/реляционных СУБД, но и, как мы думаем, объектно-
    ориентированных языков программирования общего назначения. В работе [10]
    утверждается, что верным (во всяком случае, применительно к СУБД)
    оказывается понимание типа как домена. В работе [10] защищается позиция,
    что реляционная модель является фундаментальным решением, независимым и независящим от поддержки других парадигм – объектно-ориентированной,
    императивной, функциональной (хотя авторы указывают, что некоторые сформулированные ими утверждения точны в случае применения императивного подхода и требуют некоторого уточнения при использовании

  5. Ades2015 Ответить

    Хотя она и является весьма мощной и гибкой, есть ситуации, решения которых она предложить не может. Тут на помощь придёт сравнительно новая модель, называемая NoSQL. Она набирает популярность и предлагает весьма интересные решения и дополнительный функционал. Из-за того, что эти системы не используют строгую структуризацию данных, они предлагают большую свободу действий при обработке информации.

    Реляционная модель

    Представленная в 70-х, реляционная модель предлагает математический способ структуризации, хранения и использования данных. Отношения (англ. relations) дают возможность группировки данных как связанных наборов, представленных в виде таблиц, содержащих упорядоченную информацию (например, имя и адрес человека) и соотносящих значения и атрибуты (его номер паспорта).
    Благодаря десятилетиям исследований и разработки РСУБД работают производительно и надёжно. В сочетании с большим опытом использования администраторами реляционные базы данных стали выбором, гарантирующим защиту информации от потерь.
    Несмотря на строгие принципы формирования и обработки данных, РСУБД могут быть весьма гибкими, если приложить немного усилий.

    Безмодельный (NoSQL) подход

    NoSQL-способ структуризации данных заключается в избавлении от ограничений при хранении и использовании информации. Базы данных NoSQL, используя неструктуризированный подход, предлагают много эффективных способов обработки данных в отдельных случаях (например, при работе с хранилищем текстовых документов).

    Популярные СУБД

    В этой статье мы опишем вам парадигмы основных решений для работы с базами данных. Хотя точные числа привести очень сложно, в большинстве случаев выбор делается в пользу реляционной модели или NoSQL. Прежде чем мы сравним их, давайте узнаем, что находится “под капотом” у каждой из них.

    РСУБД

    Реляционные системы управления базами данных берут своё название от реализуемой модели — реляционной. Сейчас они остаются, да и ещё какое-то время будут, самым популярным выбором для надёжного, безопасного и производительного хранения данных.
    РСУБД требуют чётких и ясных схем — не стоит путать со специфическим определением для PostgreSQL — для работы с данными. Эти рамки, определённые пользователем, задают способ их хранения и использования. Схемы очень похожи на таблицы, столбцы которых отражают порядковый номер и тип информации в каждой записи, а строки — содержимое этих записей.
    Самыми популярными РСУБД сейчас являются:
    SQLite: очень мощная встраиваемая РСУБД.
    MySQL: самая популярная и часто используемая РСУБД.
    PostgreSQL: самая продвинутая и гибкая РСУБД.

    NoSQL-СУБД

    NoSQL-СУБД не используют реляционную модель структуризации данных. Существует много реализаций, рещающих этот вопрос по-своему, зачастую весьма специфично. Эти бессхемные решения допускают неограниченное формирование записей и хранение данных в виде ключ-значение.
    В отличие от традиционных РСУБД, некоторые базы данных NoSQL, например, MongoDB, позволяют группировать коллекции данных с другими базами данных. Такие СУБД хранят данные как одно целое. Эти данные могут представлять собой одиночный объект наподобие JSON и вместе с тем корректно отвечать на запросы к полям.
    NoSQL базы данных не используют общий формат запроса (как SQL в реляционных базах данных). Каждое решение использует собственную систему запросов.

    Сравнение SQL и NoSQL

    Для того, чтобы прийти к простому и понятному выводу, давайте проанализируем разницу между SQL- и NoSQL-подходами:
    Структура и тип хранящихся данных: SQL/реляционные базы данных требуют наличия однозначно определённой структуры хранения данных, а NoSQL базы данных таких ограничений не ставят.
    Запросы: вне зависимости от лицензии, РСУБД реализуют SQL-стандарты, поэтому из них можно получать данные при помощи языка SQL. Каждая NoSQL база данных реализует свой способ работы с данными.
    Масштабируемость: оба решения легко растягиваются вертикально (например, путём увеличения системных ресурсов). Тем не менее, из-за своей современности, решения NoSQL обычно предоставляют более простые способы горизонтального масштабирования (например, создания кластера из нескольких машин).
    Надёжность: когда речь заходит о надёжности, SQL базы данных однозначно впереди.
    Поддержка: РСУБД имеют очень долгую историю. Они очень популярны, и поэтому получить поддержку, платную или нет, очень легко. Поэтому, при необходимости, решить проблемы с ними гораздо проще, чем с NoSQL, особенно если проблема сложна по своей природе (например, при работе с MongoDB).
    Хранение и доступ к сложным структурам данных: по своей природе реляционные базы данных предполагают работу с сложными ситуациями, поэтому и здесь они превосходят NoSQL-решения.

  6. DmitryModern Ответить

    Конечные пользователи.Это основная категория пользователей, в интересах которых и создается банк данных. В зависимости от особенностей создаваемого банка данных круг его конечных пользователей может существенно различаться. Это могут быть случайные пользователи, обращающиеся к БД время от времени за получением некоторой информации, а могут быть регулярные пользователи. В качестве случайных пользователей могут рассматриваться, например, возможные клиенты вашей фирмы, просматривающие каталог вашей продукции или услуг с обобщенным или подробным описанием того и другого. Регулярными пользователями могут быть ваши сотрудники, работающие со специально разработанными для них программами, которые обеспечивают автоматизацию их деятельности при выполнении своих должностных обязанностей. Например, менеджер, планирующий работу сервисного отдела компьютерной фирмы, имеет в своем распоряжении программу, которая помогает ему планировать и распределять текущие заказы, контролировать ход их выполнения, заказывать на складе необходимые комплектующие для новых заказов. Главный принцип состоит в том, что от конечных пользователей не должно требоваться каких-либо специальных знаний в области вычислительной техники и языковых средств.
    Администраторы банка данных.Это группа пользователей, которая на начальной стадии разработки банка данных отвечает за его оптимальную организацию с точки зрения одновременной работы множества конечных пользователей, на стадии эксплуатации отвечает за корректность работы данного банка информации в многопользовательском режиме. На стадии развития и реорганизации эта группа пользователей отвечает за возможность корректной реорганизации банка без изменения или прекращения его текущей эксплуатации.
    Разработчики и администраторы приложений.Это группа пользователей, которая функционирует во время проектирования, создания и реорганизации банка данных. Администраторы приложений координируют работу разработчиков при разработке конкретного приложения или группы приложений, объединенных в функциональную подсистему. Разработчики конкретных приложений работают с той частью информации из базы данных, которая требуется для конкретного приложения.

  10. VideoAnswer Ответить

Добавить ответ

Ваш e-mail не будет опубликован. Обязательные поля помечены *