Содержание
Введение
1 Постановка задачи и выбор средства разработки
1.1 Анализ предметной области
1.2 Требования к разработке
1.3 Выбор средства разработки
2 Проектирование базы данных
2.1 Основы теории баз данных
2.2 Особенности проектирования баз данных
2.3 Создание базы
2.4 создание таблиц
2.5 Конструирование диаграммы данных
2.6 Создание представлений
3 Разработка программного продукта
3.1 Клиентсерверная модель вычислений
3.2 Преимущества и недостатки вычислений клиентсервер
3.3 Создание интерфейса программы
3.4 Обработка команд
3.5 Создание классов для доступа к данным сервера
3.6 Привязка данных к элементам управления
3.7 Расчет значений по формулам
3.8 Обработка исключительных ситуаций
4 Инструкция для пользователя программы
4.1 Установка и запуск программы
4.2 Графический интерфейс пользователя
4.3 Обзор заказов
4.4 Редактирование списков
4.5 Создание нового заказа
4.6 Расчет технологических данных
4.7 Составление технологической карты
4.8 Завершение работы программы
4.9 Удаление программы
5 Мероприятия по охране труда и безопасности жизнедеятельности
5.1 Мероприятия по охране труда
5.1.1 Анализ потенциально опасных и вредных производственных факторов, пожаро и взрывоопасности проектируемого (реконструируемого) объекта
5.1.2 Инженерные мероприятия по обеспечению безопасности технологических процессов
5.1.3 Инженерные решения по обеспечению санитарногигиенических условий труда
5.1.4 Бытовые здания и помещения промышленных предприятий
5.2 Мероприятия по безопасности жизнедеятельности
5.2.1 Анализ потенциально опасных источников возникновения чс
5.2.2 Прогнозная оценка масштабов химического загрязнения объекта и прилегающей к нему территории при возникновении чс
5.2.3 Количественная оценка взрывоопасности производственных помещений и оборудования
5.2.4 Расчет инженерной защиты персонала объекта при чс. Оценка защитных свойств имеющихся убежищ (противорадиационных укрытий)
5.2.5 Мероприятия, направленные на предотвращение потерь персонала от возникновения чс
6 Экономический раздел
6.1 Общая характеристика программного средства
6.2 Исходные данные для проведения расчетов
6.3 Определение объема программного средства
6.4 Расчет трудоемкости выполняемой работы
6.5 Расчет основной заработной платы
6.6 Расчет дополнительной заработной платы
6.7 Расчет отчислений в фонд социальной защиты населения
6.8 Расчет отчислений по обязательному страхованию от несчастных случаев на производстве и профессиональных заболеваний
6.9 Расчет расходов на материалы
6.10 Расчет расходов на спецоборудование
6.11 Расчет расходов на оплату машинного времени
6.12 Расчет прочих прямых затрат
6.13 Расчет накладных расходов
6.14 Расчет суммы расходов на разработку программного средства
6.15 Расчет расходов на сопровождение и адаптацию
6.16 Расчет полной себестоимости разработки программного средства
6.17 Определение отпускной цены на программное средство
Заключение
Список использованных источников
Приложение А
Приложение Б
Приложение В
Приложение Г
Приложение Д
Приложение Е
Приложение Ж
Аннотация
Введение
В современном мире информация представляет собой один из важнейших ресурсов и, в то же время, одну из движущих сил развития человеческого общества. Во времени потоки информации имеют тенденцию к увеличению. Поэтому в любой организации, как большой, так и маленькой, возникает проблема такой организации управления данными, которая обеспечила бы наиболее эффективную работу. Некоторые организации используют для этого хранилища с папками, но большинство предпочитают компьютеризированные способы – базы данных, позволяющие эффективно хранить, структурировать и систематизировать большие объемы данных. И уже сегодня без баз данных невозможно представить работу большинства финансовых, промышленных, торговых и прочих организаций. Не будь баз данных, они просто бы не справились с обработкой поступающей информации.
Существует много веских причин перевода существующей информации на компьютерную основу. Сейчас стоимость хранения информации в файлах ЭВМ дешевле, чем на бумаге. Базы данных позволяют хранить, структурировать информацию и извлекать оптимальным для пользователя образом. Использование клиентсерверной технологии позволяют сберечь значительные средства, а главное и время для получения необходимой информации, а также упрощает доступ и ведение, поскольку она основываются на комплексной обработке данных и централизации их хранения. Эта технология дает ряд неоспоримых преимуществ, по сравнению с технологией предыдущего поколения – технологией «файлсервер». В частности, она предоставляет большие возможности по защите данных от несанкционированного доступа и разграничение прав доступа на уровне отдельных записей и полей, дает возможность работы с большими мультимедийными и нестандартными данными. Также новая технология позволяет работать как в локальных сетях, так и в глобальных и Internet, и многое другое. Системы, построенные на новой технологии «клиентсервер», отличаются высокой степенью безопасности, территориально независимости и не требовательности к аппаратной мощности клиентских станций.
Для использования столь огромных объемов хранимой информации, помимо развития системных устройств, средств передачи данных, памяти, необходимы средства обеспечения диалога человек ЭВМ, которые позволяют пользователю вводить запросы, читать файлы, модифицировать хранимые данные, добавлять новые данные или принимать решения на основании хранимых данных. Для обеспечения этих функций созданы специализированные средства – системы управления базами данных, которые специализируется на управлении массивом информации одним или множеством одновременно работающих пользователей.
В современных условиях перед предприятиями встает задача обеспечениявысокой производительности при оперативной работе большого количества пользователей. Важным моментом является то, что каждый из пользователей не зависимо от остальных, должен иметь доступ к получению необходимой ему информации. Эта задача решается с введением автоматизированных систем управления, использующих в своей основе клиентсерверную технологию. Только на основе этой технологии может быть осуществлено построение интегрированной автоматизированной системы охватывающей все предприятие или, по крайней мере, какуюлибо из подсистем управления.
Целью дипломного проекта является разработка программного обеспечения для автоматизации прохождения заказов на типографии КПУП «Колор». Конечный программный продукт состоит из программы клиента, осуществляющего ряд функций для обеспечения ввода и обработки поступающих заказов, а также базы данных заказов, в которой осуществляется хранение всей информации по заказам типографии. База данных также содержит таблицы с дополнительной информацией необходимой для расчета основных технологических данных. В дипломном проекте реализована автоматизированная система прохождения заказов.
Выполнение дипломного проекта осуществлялось в соответствии с методическими указаниями по дипломному проектированию [1].
1 Постановка задачи и выбор средства разработки
1.1 Анализ предметной области
В дипломном проекте в соответствии с заданием автоматизируется деятельность отделов, связанных с прохождением заказов на типографии КПУП «Колор».
Предметом области автоматизации являются некоторые функции деятельности отдела приема заказов и технологов предприятия.
Основное направление деятельности КПУП «Колор» – изготовление товаров народного потребления бумажнобеловой группы. Это – тетради, блокноты, ежедневники, канцелярские книги, наборы цветной бумаги и картона, альбомы и тетради для рисования, блоки для черчения, буклеты, брошюры, открытки, календари разных конфигураций и другие товары.
Все операции по сопровождению заказа осуществляются в ручном режиме. С ростом объемов производства увеличивается общее время на обработку заказов. Имеющаяся на данный момент процедура обработки заказов не имеет практически никакой автоматизации.
При обработке заказа на разных производственных стадиях, возникает необходимость оперативного контроля над состоянием заказа. В данный момент для того, чтобы узнать на какой стадии производства находится заказ, необходимо осуществить поиск заказа на каждой из стадий производства.
Для реализации указанных выше проблем можно сформулировать следующие задачи:
Проектирование и поддержание базы данных заказов. Сущность задачи состоит в создании таблиц базы данных и разработке структуры данных.
Обработка текущих данных о заказе. Сущность задачи состоит в разработке программного обеспечения для анализа входной информации и расчета основных технологических данных заказов.
Оперативный контроль над состоянием заказов. Сущность задачи состоит в осуществлении представления данных заказа в удобном для сотрудников виде.
В дипломном проекте предлагается автоматизировать работу менеджера по приему заказов, технолога, а также предоставление новых возможностей остальным сотрудникам типографии.
1.2 Требования к разработке
При разработке программного обеспечения были поставлены следующие требования:
возможность функционирования в рамках внутренней локальной сети предприятия;
регистрация всей информации связанной с заказами;
хранение данных о состоянии заказа;
возможность выдачи информации на экран монитора;
обеспечение высокой надежности хранения информации;
возможность расчета технологических данных заказа.
Представленные выше требования к программному обеспечению, могут быть реализованы при помощи выбора средств разработки, отвечающих данным требованиям.
1.3 Выбор средства разработки
Для обеспечения высокой надежности хранения данных была выбрана система управления баз данных – Microsoft SQL Server 2008. Она обеспечивает доступ к обширным ресурсам, ведущую в отрасли производительность и масштабируемость корпоративного класса, высочайший уровень безопасности, высочайший уровень доступности и высочайший уровень надежности [2].
При программной реализации необходимо учитывать множество факторов, влияющих на работоспособность создаваемого приложения. Основные критерии, предъявляемые к современным приложениям: удобство интерфейса и гибкость использования, эффективность работы, компактность и функциональность приложения.
Для разработки программного обеспечения была выбрана среда разработки Visual Studio Professional 2010, обеспечивающая высокое качество кода на протяжении всего цикла разработки программного обеспечения, от проектирования до разработки.
В качестве языка программирования был выбран Visual C# т.к. он прост, строго типизирован и объектноориентирован.
Visual Studio поддерживает Visual C# с полнофункциональным редактором кода, компилятором, шаблонами проектов, конструкторами, мастерами кода, мощным и простым в использовании отладчиком и многими другими средствами. Библиотека классов .NET Framework предоставляет доступ ко многим службам операционной системы и другим полезным, правильным классам, что существенно ускоряет цикл разработки.
Также в состав библиотеки .NET Framework входит платформа ADO.NET, которая также задействована в дипломном проекте.
ADO.NET — это набор классов, предоставляющих службы доступа к данным программисту, работающему на платформе .NET Framework. ADO.NET имеет богатый набор компонентов для создания распределенных приложений, совместно использующих данные. Это неотъемлемая часть платформы .NET Framework, которая предоставляет доступ к реляционным данным и данным приложений [3].
2 Проектирование базы данных
2.1 Основы теории баз данных
С развитием экономики возрастает объем взаимосвязанных данных, необходимых для решения коммерческих и административных задач. Взаимосвязанные данные называют информационной системой. Такая система в первую очередь призвана облегчить труд человека, но для этого она должна как можно лучше соответствовать очень сложной модели реального мира.
Ядром информационной системы являются хранимые в ней данные. На любом предприятии данные различных отделов, как правило, пересекаются, то есть используются в нескольких подразделениях или вообще являются общими. Например, для целей управления часто нужна информация по всему предприятию. Хранящиеся в информационной системе данные должны быть легко доступны в том виде, в каком они нужны для конкретной производственной деятельности предприятия. При этом не имеет существенного значения способ хранения данных. Сегодня на предприятии мы можем встретить систему обработки данных традиционного типа, в которой служащий вручную помещает данные в скоросшиватель, и рядом с ней – современную систему с применением самой быстродействующей ЭВМ, сложнейшего оборудования и программного обеспечения. Несмотря на поразительную несхожесть, обе эти системы обязаны предоставлять достоверную информацию в определенное время, определенному лицу, в определенном месте и с ограниченными затратами.
Построение информационных систем основывается на понятиях теории баз данных.
Предметной областью называется часть реальной системы, представляющая интерес для данного исследования.
При проектировании автоматизированных информационных систем предметная область отображается моделями данных нескольких уровней. Число используемых уровней зависит от сложности системы, но в любом случае включает логический и физический уровни. Предметная область может относиться к любому типу организации (например, банк, университет, малое предприятие или завод).
Необходимо различать полную предметную область (предприятие) и организационную единицу этой предметной области. Организационная единица в свою очередь может представлять свою предметную область (отделы).
Информация, необходимая для описания предметной области, зависит от реальной модели и может включать сведения о персонале, заработной плате,товарах, накладных, счетах, отчетах по сбыту, то есть сведения о людях, местах, предметах, событиях и понятиях.Объектом называется элемент информационной системы, информацию о котором мы сохраняем. В реляционной теории баз данных объект называется сущностью [4].
Объект может быть реальным (например, человек, какойлибо предмет или населенный пункт) и абстрактным (например, событие, счет покупателя или изучаемый студентами курс). Так, для складского учета примерами объектов могут служить поставщик, товар, поручение и т. д. Каждый объект обладает набором определенных свойств, которые запоминаются в информационной системе. При обработке данных часто приходится иметь дело с совокупностью однородных объектов, например служащие, и записывать информацию об одних и тех же свойствах для каждого из них [4].
Классом объектов называют совокупность объектов, обладающих одинаковым набором свойств. Таким образом, для объектов одного класса набор свойств будет одинаков.
Объекты и их свойства являются понятиями реального мира. Для информационного пространства употребляется понятие атрибута объекта.
Атрибут – это информационное отображение свойств объекта. Каждый объект характеризуется рядом основных атрибутов. Например, сотрудник предприятия имеет такие атрибуты, как фамилию, имя, отчество, адрес и возможно идентификационный номер. Каждый атрибут в модели должен иметь уникальное имя – идентификатор. Атрибут при реализации информационной модели на какомлибо носителе информации часто называют элементом данных, полем данных или просто полем.
Таблица – это некоторая регулярная структура, состоящая из конечного набора однотипных записей.
Каждая запись одной таблицы состоит из конечного числа полей, причем конкретное поле каждой записи одной таблицы может содержать данные только одного типа.
Значение данных представляет собой действительные данные, содержащиеся в каждом элементе данных. В зависимости от того, как элементы данных описывают объект, их значения могут быть количественными, качественными или описательными.
Информацию о некоторой предметной области можно представить с помощью нескольких объектов, каждый из которых описывается несколькими элементами данных. Принимаемые элементами данных значения называются данными. Единичный набор принимаемых элементами данных значений называется экземпляром объекта. Объекты связываются между собой определенным образом. Соответствующая модель объектов с составляющими их элементами данных и взаимосвязями называется концептуальной моделью. Концептуальная модель дает общее представление о потоке данных в предметной области.
Некоторые элементы данных обладают важным для построения информационной модели свойством. Если известно значение, которое принимает такой элемент данных объекта, мы можем идентифицировать значения, которые принимают другие элементы данных этого же объекта.
Ключевым элементом данных называется такой элемент, по которому можно определить значения других элементов данных.
Однозначно идентифицировать объект могут два и более элемента данных. В этом случае их называют «кандидатами» в ключевые элементы данных. Вопрос о том, какой из кандидатов использовать для доступа к объекту, решается разработчиком системы. Выбирать ключевые элементы данных следует тщательно, поскольку правильный выбор способствует созданию достоверной концептуальной модели данных.
Первичный ключ – это атрибут (или группа атрибутов), которые единственным образом идентифицируют каждую строку в таблице.
Понятие первичного ключа является исключительно важным в связи с понятием целостности баз данных.
Альтернативный ключ – это атрибут (или группа атрибутов), несовпадающий с первичным ключом и уникально идентифицирующий экземпляр объекта. Например, для объекта «служащий», который имеет атрибуты «идентификатор», «фамилия», «имя», «отчество», группа атрибутов «фамилия», «имя», «отчество» может являться альтернативным ключом по отношению к атрибуту «идентификатор».
Запись данных – это совокупность значений связанных элементов данных. Записи хранятся на некотором носителе, в качестве которого может выступать человеческий мозг, лист бумаги, память ЭВМ, внешнее запоминающее устройство и т.д.
В современных базах данных допускается хранение символьных, числовых данных, битовых строк, специализированных числовых данных (например, суммы в денежных единицах), а также данных специального формата (дата, время, временной интервал и т.д.). В любом случае при выборе типа данных необходимо учитывать возможности системы управления базами данных (СУБД), с помощью которой реализуется физическая модель информационной системы.
Доменом называется набор значений элементов данных одного типа, отвечающий поставленным условиям.
В самом общем виде домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена , и произвольного логического выражения, применяемого к элементу типа данных, который «забраковывает» недопустимые значения. Если вычисление этого логического выражения дает результат «истина», то элемент данных является элементом домена. Понятие домена может также характеризоваться как потенциальное множество допустимых значений одного типа.
Представление – это сохраняемый в базе данных именованный запрос на выборку данных (из одной или нескольких таблиц).
Результатом выполнения любого запроса на выборку данных является таблица, и поэтому концептуально можно относиться к любому представлению как к таблице.
Связь – это функциональная зависимость между сущностями.
Если между некоторыми сущностями существует связь, то факты из одной сущности ссылаются или некоторым образом связаны с фактами из другой сущности.
Поддержание непротиворечивости функциональных зависимостей между сущностями называется ссылочной целостностью. Поскольку связи содержатся «внутри» реляционной модели, реализация ссылочной целостности может выполняться как приложением, так и самой системой управления базами данных (СУБД) с помощью механизмов декларативной ссылочной целостности и триггеров.
Связи могут быть представлены пятью основными характеристиками:
тип связи (идентифицирующая, не идентифицирующая, полная/неполная категория, неспецифическая связь);
родительская сущность;
дочерняя (зависимая) сущность;
мощность связи;
допустимость пустых значений.
Связь называется идентифицирующей, если экземпляр дочерней сущности идентифицируется (однозначно определяется) через ее связь с родительской сущностью. Атрибуты, составляющие первичный ключ родительской сущности, при этом входят в первичный ключ дочерней сущности. Дочерняя сущность при идентифицирующей связи всегда является зависимой.
Связь называется не идентифицирующей, если экземпляр дочерней сущности идентифицируется иначе, чем через связь с родительской сущностью. Атрибуты, составляющие первичный ключ родительской сущности, при этом входят в состав не ключевых атрибутов дочерней сущности.
Мощность связи представляет собой отношение количества экземпляров родительской сущности к соответствующему количеству экземпляров дочерней сущности. Для любой связи, кроме неспецифической, эта связь записывается как 1:n.
Хранимые процедуры – это приложение (программа), объединяющее запросы и процедурную логику (операторы присваивания, логического ветвления и т.д.) и хранящиеся в базе данных [4].
Хранимые процедуры позволяют содержать вместе с базой данных достаточно сложные программы, выполняющие большой объем работы без передачи данных по сети и взаимодействия с клиентом. Как правило, программы, записываемые в хранимых процедурах, связаны с обработкой данных. Тем самым база данных может представлять собой функционально самостоятельный уровень приложения, который может взаимодействовать с другими уровнями для получения запросов или обновления данных.
Правила позволяют вызывать выполнение заданных действий при изменении или добавлении данных в базу данных и тем самым контролировать истинность помещаемых в нее данных.
Обычно действие – это вызов определенной процедуры или функции. Правила могут ассоциироваться с полем или записью и, соответственно, срабатывать при изменении данных в конкретном поле или записи таблицы. Нельзя использовать правила при удалении данных.
В отличие от ограничений, которые являются лишь средством контроля относительно простых условий корректности ввода данных, правила позволяют проверять и поддерживать сколь угодно сложные отношения между элементами данных в базе данных.
Триггеры – это предварительно определенное действие или последовательность действий, автоматически осуществляемых при выполнении операций обновления, добавления или удаления данных [4].
Триггер является мощным инструментом контроля над изменением данных в базе данных, а также помогает программисту автоматизировать операции, которые должны выполняться в этом случае. Триггер выполняется после проверки правил обновления данных. Ни пользователь, ни приложение не могут активизировать триггер, он выполняется автоматически, когда пользователь или приложение выполняют с базой данных определенные действия. Триггер включает в себя следующие компоненты:
Ограничения, для реализации которых собственно и создается триггер.
Событие, которое будет характеризовать возникновение ситуации, требующей проверки ограничений. События чаще всего связанны с изменением состояния баз данных (например, добавление записи в какуюлибо таблицу), но могут учитываться и дополнительные условия (например, добавление записи только с отрицательным значением).
Предусмотренное действие выполняется за счет выполнения процедуры или последовательности процедур, с помощью которых реализуется логика, требуемая для реализации ограничений.
Использование триггеров при проектировании баз данных позволяет получить при разработке приложения следующие преимущества:
Триггеры всегда выполняются при совершении соответствующих действий. Разработчик продумывает использование триггеров при проектировании базы данных и может больше не вспоминать о них при разработке приложения для доступа к данным. Если для работы с этой же базой данных вы решите создать новое приложение, триггеры и там будут отрабатывать заданные ограничения.
При необходимости триггеры можно изменять централизованно непосредственно в базе данных. Пользовательские программы, использующие данные из этой базы данных, не требуют модернизации.
Система обработки данных, использующая триггеры, обладает лучшей переносимостью в архитектуру клиентсервер за счет меньшего объема требуемых модификаций.
Ссылочная целостность – это обеспечение соответствия значения внешнего ключа экземпляра дочерней сущности значениям первичного ключа в родительской сущности.
Ссылочная целостность может контролироваться при всех операциях, изменяющих данные.
Для каждой связи на логическом уровне могут быть заданы требования по обработке операций добавления, обновления или удаления данных для родительской и дочерней сущности. Могут использоваться следующие варианты обработки этих событий:
отсутствие проверки;
проверка допустимости;
запрет операции;
каскадное выполнение операции обновления или удаления данных сразу в нескольких связанных таблицах;
установка пустого (NULL) значения или заданного значения по умолчанию.
Нормализация отношений – это процесс построения оптимальной структуры таблиц и связей в реляционной базе данных.
В процессе нормализации элементы данных группируются в таблицы, представляющие объекты и их взаимосвязи. Теория нормализации основана на том, что определенный набор таблиц обладает лучшими свойствами при включении, модификации и удалении данных, чем все остальные наборы таблиц, с помощью которых могут быть представлены те же самые данные.
2.2 Особенности проектирования баз данных
Основной формой организации хранения данных в информационных системах являются базы данных. При проектировании системы обработки данных именно данные играют важнейшую роль.
Система автоматизированной обработки данных основывается на использовании определенной модели данных или информационной модели. Модель данных отражает взаимосвязи между объектами.
Процесс создания информационной модели начинается с определения концептуальных требований ряда пользователей. Концептуальные требования могут определяться и для некоторых задач (приложений), которые в ближайшее время реализовывать не планируется. Это может несколько повысить трудоемкость работы, однако поможет наиболее полно учесть все нюансы функциональности, требуемой для разрабатываемой системы, и снизит вероятность ее переделки в дальнейшем. Требования отдельных пользователей интегрируются в едином «обобщенном представлении». Последнее называют концептуальной моделью.
Концептуальная модель представляет объекты и их взаимосвязи без указания способов их физического хранения.
Таким образом, концептуальная модель является, по существу, моделью предметной области. При проектировании концептуальной модели все усилия разработчика должны быть направлены в основном на структуризацию данных и выявление взаимосвязей между ними без рассмотрения особенностей реализации и вопросов эффективности обработки. Проектирование концептуальной модели основано на анализе решаемых на этом предприятии задач по обработке данных. Концептуальная модель включает описания объектов и их взаимосвязей, представляющих интерес в рассматриваемой предметной области и выявляемых в результате анализа данных.
Концептуальная модель транслируется затем в модель данных, совместимую с выбранной СУБД. Возможно, что отраженные в концептуальной модели взаимосвязи между объектами окажутся впоследствии нереализуемыми средствами выбранной СУБД. Это потребует изменения концептуальной модели. Версия концептуальной модели, которая может быть обеспечена конкретной СУБД, называется логической моделью.
Логическая модель отражает логические связи между элементами данных вне зависимости от их содержания и среде хранения.
Логическая модель данных может быть реляционной, иерархической или сетевой. Пользователям выделяются подмножества этой логической модели, называемые внешними моделями, отражающие их представления о предметной области. Внешняя модель соответствует представлениям, которые пользователи получают на основе логической модели. В то время как концептуальные требования отражают представления, которые пользователи первоначально желали иметь и которые легли в основу разработки концептуальной модели. Логическая модель отображается в физическую память, такую, как диск, лента или какойлибо другой носитель информации.
Физическая модель, определяющая размещение данных, методы доступа и технику индексирования, называется внутренней моделью системы.
Внешние модели никак не связаны с типом физической памяти, в которой будут храниться данные, и с методами доступа к этим данным. Это положение отражает первый уровень независимости данных. С другой стороны, если концептуальная модель способна учитывать расширение требований к системе в будущем, то вносимые в нее изменения не должны оказывать влияния на существующие внешние модели. Это – второй уровень независимости данных. Построение логической модели обусловлено требованиями используемой СУБД.
Все актуальные требования предметной области и адекватные им «скрытые» требования на стадии проектирования должны найти свое отражение в концептуальной модели. Конечно, нельзя предусмотреть все возможные варианты использования и изменения базы данных. Но в большинстве предметных областей такие основные данные, как объекты и их взаимосвязи, относительно стабильны. Меняются только информационные требования, то есть способы использования данных для получения информации.
Степень независимости данных определяется тщательностью проектирования базы данных. Всесторонний анализ объектов предметной области и их взаимосвязей минимизирует влияние изменения требований к данным в одной программе на другие программы. В этом и состоит всеобъемлющая независимость данных.
Иерархическая и сетевая модели данных стали применяться в системах управления базами данных в начале 60х годов. В начале 70х годов была предложена реляционная модель данных. Эти три модели различаются в основном способами представления взаимосвязей между объектами.
Иерархическая модель данных строится по принципу иерархии типов объектов, то есть один тип объекта является главным, а остальные, находящиеся на низших уровнях иерархии, подчиненными. Между главным и подчиненными объектами устанавливается взаимосвязь «один ко многим». Иными словами, для данного главного типа объекта существует несколько подчиненных типов объектов. В то же время для каждого экземпляра главного объекта может быть несколько экземпляров подчиненных типов объектов.
Узлы и ветви образуют иерархическую древовидную структуру. Узел является совокупностью атрибутов, описывающих объект. Наивысший в иерархии узел называется корневым (это главный тип объекта). Корневой узел находится на первом уровне. Зависимые узлы (подчиненные типы объектов) находятся на втором, третьем и др. уровнях.
В сетевой модели данных понятия главного и подчиненного объектов несколько расширены. Любой объект может быть и главным и подчиненным (в сетевой модели главный объект обозначается термином «владелец набора», а подчиненный – термином «член набора»). Один и тот же объект может одновременно выступать и в роли владельца и в роли члена набора. Это означает, что каждый объект может участвовать в любом числе взаимосвязей.
В реляционной модели данных объекты и взаимосвязи между ними представляются с помощью таблиц. Взаимосвязи также рассматриваются в качестве объектов. Каждая таблица представляет один объект и состоит из строк и столбцов. В реляционной базе данных каждая таблица должна иметь первичный ключ (ключевой элемент) – поле или комбинацию полей, которые единственным образом идентифицируют каждую строку в таблице. Благодаря своей простоте и естественности представления реляционная модель получила наибольшее распространение в СУБД для персональных компьютеров.
Все тонкости построения информационной модели преследуют однуединственную цель – получить хорошую базу данных.
Существует очень простое понятие базы данных как большого по объему хранилища, в которое организация помещает все используемые ею данные и из которого различные пользователи могут их получать, используя различные приложения. Такая единая база данных представляется идеальным вариантом, хотя на практике это решение труднодостижимо. Поэтому чаще всего под базой данных понимают любой набор хранящихся в компьютере взаимосвязанных данных.
В основу проектирования базы данных должны быть положены представления конечных пользователей конкретной организации – концептуальные требования к системе.
При рассмотрении требований конечных пользователей необходимо принимать во внимание следующее:
База данных должна удовлетворять актуальным информационным потребностям организации. Получаемая информация должна по структуре и содержанию соответствовать решаемым задачам.
База данных должна обеспечивать получение требуемых данных за приемлемое время, то есть отвечать заданным требованиям производительности.
База данных должна удовлетворять выявленным и вновь возникающим требованиям конечных пользователей.
База данных должна легко расширяться при реорганизации и расширении предметной области.
База данных должна легко изменяться при изменении программной и аппаратной среды.
Загруженные в базу данных корректные данные должны оставаться корректными.
Данные до включения в базу данных должны проверяться на корректность.
Доступ к данным, размещаемым в базе данных, должны иметь только лица с соответствующими полномочиями.
При разработке логической модели базы данных прежде всего необходимо решить, какая модель данных наиболее подходит для отображения конкретной концептуальной модели предметной области. Коммерческие системы управления базами данных поддерживают одну из известных моделей данных или некоторую их комбинацию. Большинство СУБД для персональных компьютеров поддерживают реляционную модель данных.