1.2 Описание предметной области

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

• Разработать информационно – логическую модель данных

• Отображение логической структуры данных (логическая структура определяется совокупностью логически взаимосвязанных таблиц);

Программа должна поддерживать не только возможность хранения, обработки данных, но и наличие дружественного интерфейса понятного пользователю.

Интерфейсная часть программы является понятной и удобной в использовании. Здесь обеспечивается минимальное использование клавиатуры при максимальном использовании, альтернативных клавиатуре, устройств ввода информации, в данном случае мыши. Это позволит значительно сэкономить время и соответственно повысить производительность труда.

Программа должна вести учет в реальном масштабе времени. Это означает, что в любой момент времени можно просмотреть текущую информацию по культурам, а также изменить ее.

Проектирование БД – это упорядоченный, формализованный процесс создание системы взаимосвязанных описаний, т.е. таких моделей ПО, которые связывают хранимые в базе данные с объектами ПО, описываемые этими данными. Проектирование начинается с анализа ПО и выявления функциональных и других требований к проектируемой системе.

Проектирование начинается с анализа ПО и выявления функциональных и других требований к проектируемой системе. Сначала создается обобщенное неформализованное описание создаваемой БД с использованием естественного языка, и т.д. Это инфологическая модель. Она конструктивно ограничивает область применения, а также определяет круг задач, которые будут решаться в рамках БД. Это человеко-ориентированная модель, почти не зависит от физических параметров среды хранения данных. Не изменяется до тех пор, пока изменения в реальном мире не позволят ей адекватно отражать ПО. Остальные модели машинно-ориентированные, с их помощью СУБД дает возможность программам пользователям осуществлять доступ к данным по их именам, не заботясь об их физическом расположении. Т.к. доступ к данным осуществляется с помощью конкретной СУБД, то модели должны быть представлены на ЯОД этой СУБД. Такое описание, созданное по инфологической модели, называется даталогической моделью. Для размещения и поиска данных на внешних запоминающих устройствах СУБД использует физическую модель.

Эта трехуровневая архитектура позволяет обеспечить независимость хранимых данных от использования их программ. Т.е. данные могут быть перезаписаны и реорганизованы на физическом уровне, но это повлечет только изменение физической и возможно даталогической модели, но не будет заметно для пользователя.

Также независимость данных позволяет создавать новые приложения для решения новых задач без разрушения старых.

Начальной стадией проектирования системы баз данных является построение семантической модели предметной области, которая базируется на анализе свойств и природы объектов предметной области и информационных потребностей будущих пользователей разрабатываемой системы. Эту стадию принято называть концептуальным проектированием системы, а ее результат – концептуальной моделью.

Назначение концептуальных моделей определяет и некоторые специфические требования к средствам их представления. Помимо упомянутой независимости от среды (оборудования) и требования адекватности отражения предметной области отметим следующие:

• формализованность, обеспечивающую возможность автоматизированной обработки, в том числе, например, автоматический контроль непротиворечивости;

• дружественность, обеспечивающую возможность использования наглядных графических средств отображения и обработки их пользователем.

К концептуальным моделям относятся различные компоненты, по-разному и разными средствами отражающие предметную область. Помимо наиболее известного описания объектов и связей между ними (модель «сущность-связь») к концептуальному уровню описания предметной области можно отнести следующие компоненты:

• систему атрибутов и средств описания предметной области. Например, логические (автоматические) связи между показателями или лингвистические свойства языка (синонимию, синтаксис и т.д.), используемую для вербального представления объектов;

• ограничения целостности, определяющие допустимость значения отдельных полей и взаимосвязей как на уровне семантики содержимого БД, так и ее физической структуры (отдельных файлов данных и взаимосвязей между ними);

• описание информационных потребностей пользователей, например, в виде типовых запросов, отражающих процедурные особенности обращения к данным.

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

Эту стадию называют логическим (или даталогическим) проектированием базы данных, а ее результатом является концептуальная схема базы данных, включающая определение всех информационных элементов (единиц) и связей, в том числе задание типов, характеристик и имен. Хотя даталогическое проектирование оперирует не физическими записями, а логическими понятиями, связанными со структурой базы данных, тем не менее особенности представления данных, правила и языки агрегирования и манипулирования данными имеют определенное влияние. Не все виды связей, например, «многие ко многим», могут быть непосредственно отражены в логической модели. Кроме того, может быть много вариантов отображения инфологической модели предметной области в даталогическую модель базы. Здесь следует учитывать влияние двух следующих значимых факторов, связанных с практикой разработки базы данных.

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

Во-вторых, существенным фактором может оказаться характер обработки информации. Например, частые обращения к совместно обрабатываемым данным, очевидно, предполагают их совместное хранение, а данные (особенно большого объема), к которым обращаются редко, целесообразно хранить отдельно от часто используемых. Стадия физического проектирования базы данных в общем случае включает:

• выбор способа организации базы данных;

• разработку спецификации внутренней схемы средствами модели данных ее внутреннего уровня;

• писание отображения концептуальной модели во внутреннюю.

Важно заметить, что в отличие от ранних СУБД, многие современные системы не предоставляют разработчику какого-либо на этой стадии. Реально к вопросам проектирования физической модели можно отнести выбор схемы размещения данных (разделение по файлам или тип RAID-массива) и определение числа и типа индексов (например, кластеризованный или некластеризованный в случае MS SQL Server).

Способ хранения базы данных определяется механизмами СУБД автоматически «по умолчанию» на основе спецификаций концептуальной схемы базы данных, и внутренняя схема в явном виде в таких системах не используется.

Структура программного продукта базы данных состоит из следующих блоков:

• само приложение, реализованное на языке программирования Delphi 7;

• база данных, разработанная в Microsoft Access