· Загруженные в базу данных корректные данные должны оставаться корректными.
· Данные до включения в базу данных должны проверяться на достоверность.
· Доступ к данным, размещаемым в базе данных, должны иметь только лица с соответствующими полномочиями.
· Разрешение проблем, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);
· Способы обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа;
Если инфологическая модель данных предназначена для наглядного отражения представления пользователей, т.е. является человеко-ориентированной, то даталогическая модель уже является компьютеро-ориентированной. С её помощью СУБД дает возможность программам и пользователям осуществлять доступ к хранимым данным лишь по их именам, не заботясь о физическом расположении этих данных.
Переход от инфологической модели “сущность-связь”- это сравнительно простая задача, поскольку в терминологии и принципах ER-модели и реляционного подхода имеется взаимно однозначное соответствие. Существует ряд хорошо зарекомендовавших себя правил с пощью которых из ER-диаграмм отроются реляционные таблицы.
1. Каждая простая сущность превращается в таблицу. Простая сущность - сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем таблицы.
2. Каждый атрибут становится возможным столбцом с тем же именем; может выбираться более точный формат. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, - не могут.
3. Компоненты уникального идентификатора сущности превращаются в первичный ключ таблицы. Если имеется несколько возможных уникальных идентификатора, выбирается наиболее используемый. Если в состав уникального идентификатора входят связи, к числу столбцов первичного ключа добавляется копия уникального идентификатора сущности, находящейся на дальнем конце связи (этот процесс может продолжаться рекурсивно). Для именования этих столбцов используются имена концов связей и/или имена сущностей.
4. Связи многие-к-одному (и один-к-одному) становятся внешними ключами. Т.е. делается копия уникального идентификатора с конца связи "один", и соответствующие столбцы составляют внешний ключ. Необязательные связи соответствуют столбцам, допускающим неопределенные значения; обязательные связи - столбцам, не допускающим неопределенные значения.
5. Индексы создаются для первичного ключа (уникальный индекс), внешних ключей и тех атрибутов, на которых предполагается в основном базировать запросы.
6. Если в концептуальной схеме присутствовали подтипы, то возможны два способа: все подтипы в одной таблице (а) или для каждого подтипа - отдельная таблица (б). При применении способа (а) таблица создается для наиболее внешнего супертипа, а для подтипов могут создаваться представления. В таблицу добавляется, по крайней мере, один столбец, содержащий код ТИПА; он становится частью первичного ключа. При использовании метода (б) для каждого подтипа первого уровня (для более нижних - представления) супертип воссоздается с помощью представления UNION (из всех таблиц подтипов выбираются общие столбцы - столбцы супертипа).
7. Имеется два способа работы при наличии исключающих связей: общий столбец и явные внешние ключи (б). Если остающиеся внешние ключи все в одном домене, т.е. имеют общий формат (способ (а)), то создаются два столбца: идентификатор связи и идентификатор сущности. Столбец идентификатора связи используется для различения связей, покрываемых дугой исключения. Столбец идентификатора сущности используется для хранения значений уникального идентификатора сущности на дальнем конце соответствующей связи. Если результирующие внешние ключи не относятся к одному домену, то для каждой связи, покрываемой дугой исключения, создаются явные столбцы внешних ключей; все эти столбцы могут содержать неопределенные значения.
Физическая модель данных –модель, определяющая размещение данных на внешних носителях, методы доступа и технику индексирования. Она так же называется внутренней моделью системы.
Внешние модели (даталогические модели) никак не связаны с типом физической памяти, в которой будут храниться данные, и с методами доступа к этим данным. Внутренние модели (физические модели) наоборот определяют и оперируют размещением данных и их взаимосвязях на запоминающих устройствах.
Физическая организация данных оказывает основное влияние на эксплуатационные характеристики БД. Разработчики СУБД пытаются создать наиболее производительные физические модели данных, предлагая пользователям тот или иной инструментарий для поднастройки модели под конкретную БД. Существует большое разнообразие способов реализации и корректировки физических моделей современных промышленных БД, что не позволяет рассмотреть их подробно.
Физическая модель данных является полностью компьютерно-ориентированной и конечные пользователи, а порой и прикладные программисты, не имеют никакого представления о том, каким образом данные запоминаются и извлекаются или каким способом организуются индексы в таблицах для быстрого поиска или ссылочная целостность. Эти и множество других функций по методам доступа и поддержании баз данных на внешних носителях, а также способов поиска и доступа к данным в современных СУБД обеспечивается в основном ядром базы данных, что значительно облегчает задачу создания БД и их ведение.
Трехуровневая архитектура (инфологический, даталогический и физический уровни) позволяет обеспечить независимость хранимых данных от использующих их программ. АБД может при необходимости переписать хранимые данные на другие носители информации и (или) реорганизовать их физическую структуру, изменив лишь физическую модель данных. АБД может подключить к системе любое число новых пользователей (новых приложений), дополнив, если надо, даталогическую модель. Указанные изменения физической и даталогической моделей не будут замечены существующими пользователями системы (окажутся "прозрачными" для них), так же как не будут замечены и новые пользователи. Следовательно, независимость данных обеспечивает возможность развития системы баз данных без разрушения существующих приложений.
Этапы проектирования базы данных с учетом рассмотренных выше аспектов:
1. Проектирование инфологической концептуальной модели баз данных:
а) Исследование предметной области применения и выявление требований конечных пользователей и решаемых задач.
в) Анализ данных: сбор основных данных (объекты, связи между объектами).
с) Построение ER-диаграммы базы данных.
2. Проектирование даталогической модели базы данных (учитывать требования СУБД ).
a) Потенциально возможные прикладные программы: сбор информации о потенциальных возможностях использования данных.
3. Проектирование физической модели базы данных (оценка эксплуатационных характеристик прикладных программ).
4. Реализациябазы данных (оценка при неудовлетворительных эксплуатационных характеристиках).
Для демонстрации практического примера организации базы данных с помощью описанных в дипломной работе средств, спроектируем базу данных для хранения информации о качественных характеристиках и количестве зерна пшеницы. Объект - зерноперерабатывающее предприятие мукомольной промышленности. Технология приемки зерна следующая: клиенты привозят на предприятие зерно, работники производственной лаборатории берут пробы зерна с каждой машины и проводят лабораторные анализы, в результате которых определяются такие характеристики зерна – влажность, зерновая примесь, сорная примесь, проход (сито), клейковина, натура, стекловидность. Все это качественные характеристики, от которых зависит количество муки, которое заберет клиент в обмен на зерно. Наша цель – спроектировать базу данных, в которой будет храниться информация о зерне, принятом от клиентов. Подразумевается, что информация накапливается постоянно с каждым днем, она может изменяться; данная база данных является частью большого комплекса автоматизированной системы управления предприятием (АСУП).
База данных несомненно носит характер фактографической информационной системы и должна выдавать однозначные сведения на поставленные запросы. Конечными пользователями базы данных являются работники производственной лаборатории, зерноперерабатывающего цеха, бухгалтерии (отдел сбыта готовой продукции), которые относятся к категории пользователей не искушенных в вопросах ведения, администрирования баз данных и поддержании их в актуальном состоянии. Это накладывает определенные требования на разработку системы управления базой данных, при которой все методы доступа, поиска и большинство функций администрирования скрыты внутри программы и прозрачны при работе что, несомненно, скажется на разработке программного интерфейса. Более подробно все требования перечислены ниже:
1. Предоставление общей информации о количестве принятого зерна и его качественных характеристиках. Это совокупность сведений о количестве зерна, привезенном каждым клиентом, включает в себя общую информацию такую как название фирмы клиента или фамилия (если это физическое лицо), дата приемки зерна, номер автомашины, класс пшеницы, масса брутто (с автомашиной), масса тары (автомашины), масса нетто (чисто зерно), номер склада (куда поступило зерно). Подразумевается, что информация будет изменятся и пополнятся постоянно.