Разработка базы городской телефонной сети

Тип работы:
Курсовая
Предмет:
Программирование


Узнать стоимость

Детальная информация о работе

Выдержка из работы

1. Теоретическая часть

1.1 Общая характеристика предметной области и анализ объекта исследования

ГТС представляет собой разветвленную сеть локальных АТС. АТС подразделяются на городские, ведомственные и учрежденческие и, возможно, обладают характерным только для этой группы набором атрибутов. У каждой АТС есть свои абоненты. У абонента может стоять телефон одного из трех типов: основной, параллельный или спаренный. За каждым абонентом (у него есть фамилия, имя, отчество, пол, возраст и т. д.) закреплен свой номер телефона, причем у нескольких абонентов может быть один и тот же номер (при параллельном или спаренном телефоне). Каждому номеру телефона соответствует адрес (индекс, район, улица, дом, квартира), причем параллельные или спаренные телефоны обязательно должны находиться в одном доме.

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

Сведения о междугородных переговорах собираются и анализируются на ГТС.

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

Абонентов любой АТС можно подразделить на простых и льготных. К категории льготников относятся пенсионеры, инвалиды и т. д. Льготники платят только 50% абонентской платы. В соответствии со всем этим (тип телефона, льготник или нет, есть ли выход на межгород) рассчитывается размер абонентской платы.

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

В городе также существуют общественные телефоны и таксофоны, расположенные по определенным адресам.

Концептуальная модель является представлением точки зрения пользователя на предметную область и не зависит ни от программного обеспечения СУБД, ни от технических решений. Она стабильна.

Одной из распространенных моделей концептуальной схемы является модель «сущность — связь». Под сущностью понимают основное содержание объекта предметной области, о котором собирают информацию. В качестве сущности могут выступать место, вещь, личность, явление.

Экземпляр сущности — конкретный объект.

Сущность принято определять атрибутами — поименованными характеристиками.

1.2 Постановка и развернутое описание решаемой задачи

Создание базы данных, для хранения и обработки информации городской телефонной станции. Для обеспечения пользователя указанной информацией в базах данных должны храниться справочные данные об абонентах ГТС, об общественных телефонах и таксофонах, сведения об очереди на подключение. В результате анализа предметной области выявляются документы, содержащие справочную и учетную информацию: «Сведения об абонентах», «Сведения о клиентах», «Перечень таксофонов», «Очередь на подключение».

База данных — представленная в объективной форме совокупность самостоятельных материалов (статей, расчётов, нормативных актов, судебных решений и иных подобных материалов), систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины (ЭВМ).

1. БД включает схему, или метаданные, описывающие логическую структуру БД в формальном виде (в соответствии с некоторой метамоделью).

2. В соответствии с ГОСТ Р ИСО МЭК ТО 10 032−2007, «постоянные данные в среде базы данных включают в себя схему и базу данных. Схема включает в себя описания содержания, структуры и ограничений целостности, используемые для создания и поддержки базы данных. База данных включает в себя набор постоянных данных, определённых с помощью схемы. Система управления данными использует определения данных в схеме для обеспечения доступа и управления доступом к данным в базе данных».

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

В это же время в сообществе баз данных COBOL была проработана концепция схем баз данных и концепция независимости данных.

В широком аспекте понятие истории баз данных обобщается до истории любых средств, с помощью которых человечество хранило и обрабатывало данные. В таком контексте упоминаются, например, средства учёта царской казны и налогов в древнем Шумере (4000 г. до н.э.), узелковая письменность инков — кипу, клинописи, содержащие документы Ассирийского царства и т. п. Следует помнить, что недостатком этого подхода является размывание понятия «база данных» и фактическое его слияние с понятиями «архив» и даже «письменность».

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

4. Структурированность подразумевает явное выделение составных частей (элементов), связей между ними, а также типизацию элементов и связей, при которой с типом элемента (связи) соотносится определённая семантика и допустимые операции.

Из перечисленных признаков только первый является строгим, а другие допускают различные трактовки и различные степени оценки. Можно лишь установить некоторую степень соответствия требованиям к БД.

История

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

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

Оперативные сетевые базы данных появились в середине 1960-х. Операции над оперативными базами данных обрабатывались в интерактивном режиме с помощью терминалов. Простые индексно-последовательные организации записей быстро развились к более мощной модели записей, ориентированной на наборы. За руководство работой Data Base Task Group (DBTG), разработавшей стандартный язык описания данных и манипулирования данными, Чарльз Бахман получил Тьюринговскую премию.

5. Признаки Базы данных:

6. БД хранится и обрабатывается в вычислительной системе.

7. Таким образом, любые внекомпьютерные хранилища информации (архивы, библиотеки, картотеки и т. п.) базами данных не являются.

Сам термин база данных (англ. database) появился в начале 1960-х годов, и был введён в употребление на симпозиумах, организованных фирмой SDC (System Development Corporation) в 1964 и 1965 годах, хотя понимался сначала в довольно узком смысле, в контексте систем искусственного интеллекта. В широкое употребление в современном понимании термин вошёл лишь в 1970-е годы.

Следующий важный этап связан с появлением в начале 1970-х реляционной модели данных, благодаря работам Эдгара Ф. Кодда. Работы Кодда открыли путь к тесной связи прикладной технологии баз данных с математикой и логикой. За свой вклад в теорию и практику Эдгар Ф. Кодд также получил премию Тьюринга.

1.3 Исследование потоков данных

Данные поступают из обычных источников: телефонных звонков, анкет, документации и т. д. и заполняются оператором через соответствующую форму. Так как поле «Н_телефона» является ключом в главной таблицы, то для внесения новых записей в таблицу «Клиенты» необходимо предварительно внести соответствующую запись с присвоенным клиенту номером телефона в таблицу «Абоненты».

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

1.4 Перечень задач, подлежащих решению

Разработка концептуальной модели локальной базы данных;

Разработка проекта СУБД в соответствии с техническим заданием;

Реализация проекта и разработка технической документации.

На стадии разработки концептуальной модели базы данных необходимо выполнить следующие этапы:

· определение цели создания ИИС;

· установление состава пользователей БД;

· разработка концептуальной модели БД;

· разработка технического задания на проектирование СУБД;

· определение потребных трудовых и материальных ресурсов для разработки БД.

Конечной задачей разработки концептуальной модели является установление оптимального состава таблиц базы данных.

После определения состава таблиц базы данных можно приступить к разработке технического задания на проектирование СУБД. В техническом задании необходимо:

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

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

На стадии разработки проекта СУБД в соответствии с техническим заданием необходимо выполнить следующие задачи:

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

Разработка оптимального состава и структуры таблиц базы данных;

Установление логических связей между таблицами;

Разработка необходимого числа запросов для реализации поставленной задачи;

Разработка необходимого числа отчетов, отвечающих требованиям к выходным документам, определенных техническим заданием;

Реализация проекта разработанной СУБД сводится к следующим задачам:

· заполнение таблиц баз данных информацией об объектах;

· проверка функционирования СУБД при выполнении поставленных задач;

· разработка инструкций для пользователей;

1.5 Средства решения поставленной задачи

Microsoft Access, язык SQL.

Microsoft Office Access или просто Microsoft Access — реляционная СУБД корпорации Microsoft. Имеет широкий спектр функций, включая связанные запросы, связь с внешними таблицами и базами данных. Благодаря встроенному языку VBA, в самом Access можно писать приложения, работающие с базами данных.

Состав программного продукта

· построитель таблиц;

· построитель экранных форм;

· построитель SQL-запросов (язык SQL в MS Access не соответствует стандарту ANSI);

· построитель отчётов, выводимых на печать.

Они могут вызывать скрипты на языке VBA, поэтому MS Access позволяет разрабатывать приложения и БД практически «с нуля» или написать оболочку для внешней БД.

Microsoft Jet Database Engine (англ.), которая используется в качестве движка базы данных MS Access является файл-серверной СУБД и потому применима лишь к приложениям, работающим с небольшими объёмами данных и при небольшом числе пользователей, одновременно работающих с этим данными. Непосредственно в Access отсутствует ряд механизмов, необходимых в многопользовательских БД, таких, например, как триггеры.

Взаимодействие с другими СУБД

Встроенные средства взаимодействия MS Access со внешними СУБД с использованием интерфейса ODBC снимают ограничения, присущие Microsoft Jet Database Engine. Инструменты MS Access, которые позволяют реализовать такое взаимодействие называются «связанные таблицы» (связь с таблицей СУБД) и «запросы к серверу» (запрос на диалекте SQL, который «понимает» СУБД).

Корпорация Microsoft для построения полноценных клиент-серверных приложений на базе MS Access рекомендует использовать в качестве движка базы данных СУБД MS SQL Server. При этом имеется возможность совместить с присущей MS Access простотой инструменты для управления БД и средства разработки. Известны также реализации клиент-серверных приложений на базе связки Access 2003 c другими СУБД, в частности, MySQL.

Таблица 1 — Совместимость Access со сторонними источниками данных

СУБД (Источник данных)

Версия Access

Драйвер

Обновляемые запросы

Файлы Excel

все

встроенный

Нет

SQLite

Да

MySQL

2000−2003

MyODBC v. 3. 51. X, 5.1. X

Да

PostgreSQL

Да

Firebird

Да

1C v. 7.7 (dbf)

2003

Visual FoxPro ODBC driver v. 6. 01. 8629. 01

Нет

Paradox

Oracle

Текстовые файлы

все

встроенный

Нет

Таблицы html

все

встроенный

Нет

Практические аспекты лицензирования Access

Microsoft Access является проприетарным программным обеспечением, то есть для его использования необходимо приобрести лицензию. Однако для использования готовых приложений, созданных с помощью Access, лицензия не требуется. Для работы такого приложения необходима runtime-версия Access, которая распространяется бесплатно.

Корпорация Microsoft распространяет полнофункциональную версию Access как отдельно, так и совместно с другими приложениями (Word, Excel и др.) в составе пакетов Microsoft Office Professional, Microsoft Office Professional Plus и Microsoft Office Enterprise.

Microsoft Office 2007

Системные требования:

· Частота процессора не менее 500 МГц

· Не менее 256 Мб оперативной памяти

· 1,5−2 Гб свободного места на жёстком диске

· Разрешение экрана не менее 1024×768 точек

· Операционная система Windows XP с SP2, Windows Server 2003 с SP2 или более новые версии.

Язык SQL.

SQL (англ. Structured Query Language — «язык структурированных запросов») — универсальный компьютерный язык, применяемый для создания, модификации и управления данными в реляционных базах данных. SQL основывается на исчислении кортежей.

SQL является, прежде всего, информационно-логическим языком, предназначенным для описания, изменения и извлечения данных, хранимых в реляционных базах данных. SQL нельзя назвать языком программирования.

Изначально, SQL был основным способом работы пользователя с базой данных и позволял выполнять следующий набор операций:

· создание в базе данных новой таблицы;

· добавление в таблицу новых записей;

· изменение записей;

· удаление записей;

· выборка записей из одной или нескольких таблиц (в соответствии с заданным условием);

· изменение структур таблиц.

Со временем, SQL усложнился — обогатился новыми конструкциями, обеспечил возможность описания и управления новыми хранимыми объектами (например, индексы, представления, триггеры и хранимые процедуры) — и стал приобретать черты, свойственные языкам программирования.

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

Каждое предложение SQL — это либо запрос данных из базы, либо обращение к базе данных, которое приводит к изменению данных в базе. В соответствии с тем, какие изменения происходят в базе данных, различают следующие типы запросов:

· запросы на создание или изменение в базе данных новых или существующих объектов (при этом в запросе описывается тип и структура создаваемого или изменяемого объекта);

· запросы на получение данных;

· запросы на добавление новых данных (записей)

· запросы на удаление данных;

· обращения к СУБД.

Основным объектом хранения реляционной базы данных является таблица, поэтому все SQL-запросы — это операции над таблицами. В соответствии с этим, запросы делятся на

· запросы, оперирующие самими таблицами (создание и изменение таблиц);

· запросы, оперирующие с отдельными записями (или строками таблиц) или наборами записей.

Каждая таблица описывается в виде перечисления своих полей (столбцов таблицы) с указанием

· типа хранимых в каждом поле значений;

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

· информации, необходимой для построения индексов.

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

· вставка новой строки;

· изменение значений полей строки или набора строк;

· удаление строки или набора строк.

Самый главный вид запроса — это запрос, возвращающий (пользователю) некоторый набор строк, с которым можно осуществить одну из трёх операций:

· просмотреть полученный набор;

· изменить все записи набора;

· удалить все записи набора.

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

Первые разработки

В начале 1970-х годов в одной из исследовательских лабораторий компании IBM была разработана экспериментальная реляционная СУБД IBM System R, для которой затем был создан специальный язык SEQUEL, позволявший относительно просто управлять данными в этой СУБД. Аббревиатура SEQUEL расшифровывалась как Structured English QUEry Language — «структурированный английский язык запросов». Позже по юридическим соображениям язык SEQUEL был переименован вSQL. Когда в 1986 году первый стандарт языка SQL был принят ANSI (American National Standards Institute), официальным произношением стало — эс-кью-эл. Несмотря на это, даже англоязычные специалисты зачастую продолжают читать SQL как сиквел (по-русски часто говорят «эс-ку-эль» или используют жаргонизм «скуль»).

Целью разработки было создание простого непроцедурного языка, которым мог воспользоваться любой пользователь, даже не имеющий навыков программирования. Собственно разработкой языка запросов занимались Дональд Чэмбэрлин (Donald D. Chamberlin) и Рэй Бойс (Ray Boyce). Пэт Селинджер (Pat Selinger) занималась разработкой стоимостного оптимизатора (cost-based optimizer), Рэймонд Лори (Raymond Lorie) занимался компилятором запросов.

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

Первыми СУБД, поддерживающими новый язык, стали в 1979 году Oracle V2 для машин VAX от компании Relational Software Inc. (впоследствии ставшей компаниейOracle) и System/38 от IBM, основанная на System/R.

Стандартизация

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

В 1983 году Международная организация по стандартизации (ISO) и Американский национальный институт стандартов (ANSI) приступили к разработке стандарта языка SQL. По прошествии множества консультаций и отклонения нескольких предварительных вариантов в 1986 году ANSI представил свою первую версию стандарта, описанного в документе ANSI X3. 135−1986 под названием «Database Language SQL» (Язык баз данных SQL). Неофициально этот стандарт SQL-86 получил название SQL1. Год спустя, была завершена работа над версией стандарта ISO 9075−1987 под тем же названием. Разработка этого стандарта велась под патронажем Технического Комитета TC97 (англ. Technical Committee TC97), областью деятельности которого являлись процессы вычисления и обработки информации (англ. Computing and Information Processing). Именно его подразделение, именуемое как Подкомитет SC21 (англ. Subcommittee SC21) курировало разработку стандарта, что стало залогом идентичности стандартов ISO и ANSI для SQL1 (SQL-86).

Стандарт SQL1 разделялся на два уровня. Первый уровень представлял собой подмножество второго уровня, описывавшего весь документ в целом. То есть, такая структура предусматривала, что не все спецификации стандарта SQL1 будут относиться к Уровню 1. Тем самым, поставщик, заявлявший о поддержке данного стандарта, должен был заявлять об уровне, которому соответствует его реализация языка SQL. Это значительно облегчило принятие и поддержку стандарта, поскольку производители могли реализовывать его поддержку в два этапа.

Со временем к стандарту накопилось несколько замечаний и пожеланий, особенно с точки зрения обеспечения целостности и корректности данных, в результате чего в 1989 году данный стандарт был расширен, получив название SQL89. В частности, в него была добавлена концепция первичного и внешнего ключей. ISO-версия документа получила название ISO 9075: 1989 «Database Language SQL with Integrity Enhancements» (Язык баз данных SQL с добавлением контроля целостности). параллельно была закончена и ANSI-версия.

Сразу после завершения работы над стандартом SQL1 в 1987 году была начата работа над новой версией стандарта, который должен был заменить стандарт SQL89, получив название SQL2, поскольку дата принятия документа на тот момент была неизвестна. Таким образом, фактически SQL89 и SQL2 разрабатывались параллельно. Новая версия стандарта была принята в 1992 году, заменив стандарт SQL89. Новый стандарт, озаглавленный как SQL92, представлял собой по сути расширение стандарта SQL1, включив в себя множество дополнений имевшихся в предыдущих версиях инструкций.

Как и SQL1, SQL92 также был разделён на несколько уровней, однако, во-впервых, число уровней было увеличено с двух до трёх, а во-вторых они получили названия вместо порядковых цифр: начальный (англ. entry), средний (англ. intermediate), полный (англ. full). Уровень «полный» как и Уровень 2 в SQL1 подразумевал весь стандарт целиком. Уровень «начальный» представлял собой подмножество уровня «средний», в свою очередь представлявшего собой подмножество уровня «полный». Уровень «начальный» был сравним с Уровнем 2 стандарта SQL1, но спецификации этого уровня были несколько расширены. Таким образом, цепочка включений уровней стандартов выглядела примерно следующим образом: SQL1 Уровень 1 > SQL1 Уровень 2 > SQL92 «Начальный» > SQL92 «Средний» > SQL92 «Полный».

После принятия стандарта SQL92 к нему были добавлены ещё несколько документов, расширявших функциональность языка. Так, в 1995 году был принят стандарт SQL/CLI (Call Level Interface, интерфейс уровня вызовов), впоследствии переименованный в CLI95. На следующий год был принят стандарт SQL/PSM (Persistent Stored Modules, постоянно хранимые модули), получивший название PSM-96.

2. Разработка и реализация проекта базы данных

2.1 Инфологическое моделирование системы

Информационно логическая схема БД «ГТС» (Рисунок 1).

В общем случае в соответствии с процесс проектирования базы данных состоит из трёх этапов:

* концептуальное проектирование

* логическое проектирование

* физическое проектирование.

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

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

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

Внешние модели. Информационные потребности пользователей отражают внешние модели. Эти модели образуют представления соответствующих пользователей (задач) о базе данных. Каждая внешняя модель является некоторым подмножеством базы данных. Такие подмножества могут пересекаться, то есть часть данных различных моделей может быть одинаковой.

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

Рисунок 1 — Использование производственных мощностей (в%)

2.2 Определение логической структуры реляционной базы данных

Таблица 2 — Логическая структура таблицы «Клиенты»

Документ

Наименование реквизита

Обозначение реквизита

Функциональные зависимости

Клиенты

Код абонента

Фамилия

Имя

Отчество

Пол

Возраст

Номер телефона

Тип телефона

Код_аб

Фамилия

Имя

Отчество

Пол

Возраст

№телефона

Тип_телефона

Счетчик ключ

Таблица 3 — Логическая структура таблицы «Абоненты»

Документ

Наименование реквизита

Обозначение

реквизита

Функциональные зависимости

Абоненты

Номер телефона

Льготы

Межгород

Оплата

Размер оплаты

Код АТС

№телефона

Льготы

Межгород

Оплата

Размер_оплаты

Код_АТС

Составной ключ

Таблица 4 — Логическая структура таблицы «АТС»

Документ

Наименование реквизита

Обозначение

реквизита

Функциональные зависимости

АТС

Код АТС

Тип АТС

Адрес АТС

Код_АТС

Тип

Адрес

Счетчик ключ

Таблица 5 — Логическая структура таблицы «Установка»

Документ

Наименование реквизита

Обозначение

реквизита

Функциональные зависимости

Установка

Код абонента

Очередь

Техническая возможность

Код АТС

Код_аб

Очередь

Тех_возм

Код_АТС

Счетчик ключ

Таблица 6 — Логическая структура таблицы «Таксофоны»

Документ

Наименование реквизита

Обозначение

реквизита

Функциональные зависимости

Таксофоны

Код таксофона

Адрес таксофона

Код АТС

Код_такс

Адрес

Код_АТС

Счетчик ключ

2.3 Нормализация проекта базы данных

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

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

· исключение некоторых типов избыточности;

· устранение некоторых аномалий обновления;

· разработка проекта базы данных, который является достаточно «качественным» представлением реального мира, интуитивно понятен и может служить хорошей основой для последующего расширения;

· упрощение процедуры применения необходимых ограничений целостности.

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

Роль нормализации в проектировании реляционных баз данных

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

Нормализацию иногда упрекают на том основании, что «это просто здравый смысл», а любой компетентный профессионал и сам «естественным образом» спроектирует полностью нормализованную БД без необходимости применять теорию зависимостей. Однако, как указывает К. Дейт, нормализация в точности и является теми принципами здравого смысла, которыми руководствуется в своём сознании зрелый проектировщик, то есть принципы нормализации — это формализованный здравый смысл. Между тем, идентифицировать и формализовать принципы здравого смысла — весьма трудная задача, и успех в её решении является существенным достижением.

Нормальные формы

Первая нормальная форма (1NF)

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

В реляционной модели отношение всегда находится в первой нормальной форме по определению понятия отношение. Что же касается различных таблиц, то они могут не быть правильными представлениями отношений и, соответственно, могут не находиться в 1НФ.

Вторая нормальная форма (2NF)

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

Третья нормальная форма (3NF)

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

Четвёртая нормальная форма (4NF)

Переменная отношения находится в четвёртой нормальной форме, если она находится в нормальной форме Бойса — Кодда и не содержит нетривиальных многозначных зависимостей.

Пятая нормальная форма (5NF)

Переменная отношения находится в пятой нормальной форме (иначе — в проекционно-соединительной нормальной форме) тогда и только тогда, когда каждая нетривиальная зависимость соединения в ней определяется потенциальным ключом (ключами) этого отношения.

Доменно-ключевая нормальная форма (DKNF)

Переменная отношения находится в ДКНФ тогда и только тогда, когда каждое наложенное на неё ограничение является логическим следствием ограничений доменов и ограничений ключей, наложенных на данную переменную отношения.

Ограничение домена — ограничение, предписывающее использовать для определённого атрибута значения только из некоторого заданного домена. Ограничение по своей сути является заданием перечня (или логического эквивалента перечня) допустимых значений типа и объявлением о том, что указанный атрибут имеет данный тип.

Ограничение ключа — ограничение, утверждающее, что некоторый атрибут или комбинация атрибутов является потенциальным ключом.

Любая переменная отношения, находящаяся в ДКНФ, обязательно находится в 5НФ. Однако не любую переменную отношения можно привести к ДКНФ.

Шестая нормальная форма (6NF)

Введена К. Дейтом в его книге, как обобщение пятой нормальной формы для темпоральной базы данных.

Переменная отношения находится в шестой нормальной форме тогда и только тогда, когда она удовлетворяет всем нетривиальным зависимостям соединения. Из определения следует, что переменная находится в 6НФ тогда и только тогда, когда она неприводима, то есть не может быть подвергнута дальнейшей декомпозиции без потерь. Каждая переменная отношения, которая находится в 6НФ, также находится и в 5НФ.

БД представлена в 1 нормальной форме, т. к. в любом допустимом значении отношения каждый его кортеж содержит только одно значение для каждого из атрибутов. Дальнейшее приведение до 3NF не желательно, т. к. это усложнит структуру БД, увеличит время выполнения запросов и операций с БД.

2.4 Реализация проекта базы данных в среде СУБД

2.4.1 Конструирование таблиц базы данных

Таблица «Абоненты» (Рисунок 2)

Рисунок 2 — Таблица «Абоненты».

Для поля «Н_телефона» установлена маска вода «0», которая обуславливает возможность ввода комбинаций лишь из 6 цифр.

Для полей «Льготы», «Межгород», «Оплата», установлен выбор значения из логических «Да"/ «Нет».

Для поля «Код_АТС» установлен список возможных значений из таблицы «АТС».

Таблица «Установка» (Рисунок 3)

Рисунок 3 — Таблица «Установка».

Для поля «Код_АТС» установлен список возможных значений из таблицы «АТС».

Таблица «Клиенты» (Рисунок 4)

Рисунок 4 — Таблица «Клиенты».

Для поля «Н_телефона» установлена маска вода «0», которая обуславливает возможность ввода комбинаций лишь из 6 цифр.

Для поля «Тип_телефона установлен выбор значения из фиксированного списка (Основной, Параллельный, Спаренный).

Для поля «Пол» установлен набор значений из фиксированного списка.

Рисунок 5 — Таблица «АТС».

Для поля «Тип» установлен выбор значения из фиксированного списка (Городская, Ведомственная, Учережденческая).

Таблица «Таксофоны» (Рисунок 6)

Рисунок 5 — Таблица «АТС».

Для поля «Код_АТС» установлен список возможных значений из таблицы «АТС».

2.4. 2 Создание схемы данных. Ограничение целостности в БД

Целостность базы данных (database integrity) — соответствие имеющейся в базе данных информации её внутренней логике, структуре и всем явно заданным правилам. Каждое правило, налагающее некоторое ограничение на возможное состояние базы данных, называется ограничением целостности (integrity constraint). Примеры правил: вес детали должен быть положительным; количество знаков в телефонном номере не должно превышать 6; возраст родителей не может быть меньше возраста их биологического ребёнка и т. д.

Задача аналитика и проектировщика базы данных — возможно более полно выявить все имеющиеся ограничения целостности и задать их в базе данных.

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

2.5 Реализация защиты базы данных

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

Эти два подхода отличаются следующими свойствами:

· В случае избирательного управления некоторый пользователь обладает различными правами (привилегиями или полномочиями) при работе с данными объектами. Разные пользователи могут обладать разными правами доступа к одному и тому же объекту. Избирательные права характеризуются значительной гибкостью.

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

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

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

· Привилегии или полномочия пользователей или групп — это набор действий (операций), которые они могут выполнять над объектами БД.

· В последних версиях ряда коммерческих СУБД появилось понятие «роли». Роль — это поименованный набор полномочий. Существует ряд стандартных ролей, которые определены в момент установки сервера баз данных. И имеется возможность создавать новые роли, группируя в них произвольные полномочия. Введение ролей позволяет упростить управление привилегиями пользователей, структурировать этот процесс. Кроме того, введение ролей не связано с конкретными пользователями, поэтому роли могут быть определены и сконфигурированы до того, как определены пользователи системы.

· Пользователю может быть назначена одна или несколько ролей.

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

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

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

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

СУБД в своих системных каталогах хранит как описание самих пользователей, так и описание их привилегий по отношению ко всем объектам.

Стандартные способы защиты

Защита с использованием пароля БД

Данный способ защиты позволяет установить пароль на открытие БД, для всех пользователей. Для его создания необходимо открыть файл БД в «монопольном» режиме и выбрать пункт меню Сервис / Защита / Задать пароль базы данных. Для работы с такой базой данных в MS Access потребуется вводить пароль. Вот пример работы с файлом БД, используя DAO или ADO.

Public Sub TestDAO ()

Dim mWS As DAO. Workspace

Dim mDB As DAO. Database

Set mWS = DBEngine. Workspaces (0)

Set mDB = mWS. OpenDatabase _

(«C: a97. mdb», True, True,"; pwd=123″)

End Sub

Public Sub TestADO ()

Dim CnDB As New ADODB. Connection

CnDB. Open «Provider=Microsoft. Jet. OLEDB.4. 0» & _

"; Data Source=C: a97. mdb" & _

"; Jet OLEDB: Database Password=123″

End Sub

Это самый не надёжный способ защиты баз данных. Существует достаточное количество бесплатных и платных утилит, отображающих пароль. В том числе доступны исходники кода на VB позволяющие прочитать такой пароль. В прочем не всё так плохо. Существует оригинальная модификация этого способа защиты, о котором речь пойдёт ниже.

Защита с использованием пароля пользователя

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

Последовательность действий для создания защищённого файла:

· Создание нового файла рабочих групп.

· Для этого в 97−2000 Access запускается программа WRKGADM. EXE, а в 2003 Access необходимо выбрать пункт меню «Сервис / Защита / Администратор рабочих групп». В администраторе жмём кнопку «Создать», указываем имя, организацию и код группы. Указываем имя и расположение создаваемого файла. Например:

· Имя: test_Имя

· Opгaнизaция: ~

· Кoд paбoчeй гpyппы: cтpoчкa 20 cимвoлoв.

· Фaйл paбoчeй гpyппы: C: testgr. mdw

· Создание ярлыка, для запуска ms Access с использованием созданного mdw файла. Ярлык должен содержать строку: [путь к MSACCESS. EXE] /WrkGrp [путь к файлу mdw]. Например: «C: Program FilesMSOffice2003OFFICE11MSACCESS. EXE» /WrkGrp C: testgr. mdw

· Запустив Access c помощью этого ярлыка необходимо открыть пункт меню «Сервис / Защита / Пользователи и группы». В открывшемся диалоговом окне необходимо создать нового пользователя и добавить его в группу «Admins». Например, был создан «test_Пользователь» с кодом «987 654 321»

· Теперь необходимо открыть Access от имени созданного пользователя. Для этого необходимо добавить в созданный ярлык строку: /user [имя пользователя]. Например: «C: Program FilesMSOffice2003OFFICE11MSACCESS. EXE» /WrkGrp C: testgr. mdw /User test_Пользователь

· Запускаем Access c помощью этого ярлыка. Теперь созданному пользователю необходимо присвоить пароль. Это делается в том же диалоге «Пользователи и группы». Допустим пользователю «test_Пользователь» присвоен пароль «test_Пароль». Далее, необходимо создать новую БД. При этом владельцем этой базы, а также всех создаваемых или импортируемых объектов (таблиц, запросов и.т. п.) будет пользователь имя которого было указано в ярлыке.

· После того, как БД будет создана желательно удалить «Admin» из группы «Admins» и отобрать у группы «Users» права на объекты БД и на открытие базы.

· Добавляем в ярлык название защищённой БД. Например: «C: Program FilesMSOffice2003OFFICE11MSACCESS. EXE» C: testdb2k_test. mdb /WrkGrp C: testgr. mdw /User test_Пользователь /pwd test_Пароль

Вот пример открытия БД защищённой на уровне пользователей с помощью DAO или ADO

Public Sub TestDAO ()

Dim mWS As DAO. Workspace

Dim mDB As DAO. Database

DBEngine. SystemDB = «C: testgr. mdw»

Set mWS = DBEngine. CreateWorkspace _

(««, «test_Пользователь», «test_Пароль», dbUseJet)

Set mDB = mWS. OpenDatabase _

(«C: testa97. mdb», True)

End Sub

Public Sub TestADO ()

Dim CnDB As New ADODB. Connection

CnDB. Open «Provider=Microsoft. Jet. OLEDB.4. 0;» & _

«Data Source=C: testa97. mdb;» & _

«Jet OLEDB: System database=C: testgr. mdw;» & _

«User ID=test_Пользователь;» & _

«Password=test_Пароль; «

End Sub

Снятие такой защиты.

Создать новую БД. В ярлыке прописать путь к этой БД, MDW файл защищённой БД имя и пароль владельца. Открыть с помощью этого ярлыка новую БД. Импортировать в неё таблицы из защищённой, после чего сменить для всех объектов БД владельца на Admin. Для того, чтобы узнать имя и пароль владельца БД можно воспользоваться специализированными программами, описанными в обзоре Пароли Access. При отсутствии файла рабочих групп его можно восстановить. Для этого потребуется узнать имена и идентификаторы владельцев объектов БД. Эта информация содержится в файле базы данных и может быть извлечена с помощью таких программ как AOPR. Используя эти данные создаётся новый файл. (последовательность описана выше).

Совсем не обязательно использовать программы, позволяющие определить пароль БД или пользователя. Часто программисты совсем не заботятся о сокрытии пароля в тексте программы. Запустив программу, работающую с защищённой БД необходимо открыть в шестнадцатеричном редакторе WinHex виртуальную память этого приложения. Проведя поиск Unicode строк 'User ID='; 'Password='; 'Database Password=' или 'pwd=' можно найти имя пользователя, его пароль и пароль базы данных.

Можно вовсе проигнорировать наличие защиты. Для этого надо воспользоваться AccessRecovery, которая создаёт новый файл без защиты и переносит в него таблицы, запросы, формы, макросы, отчеты и код модулей.

Нестандартные способы защиты

Изменение расширения файла

Достаточно простой способ ввести в заблуждение — изменение расширения файла БД. Увидев незнакомое расширение, не каждый попытается выяснить природу этого файла. Кроме этого появляется возможность связать это расширение с вашей программой, так чтобы при клике по файлу запускалось ваше приложение, а не Access. Желательно открывать такой файл с монопольным доступом, так как в этом случае не будет создаваться ldb файл.

Защита с использованием пароля БД, содержащего непечатные символы

В первую очередь этот способ нацелен на противодействие определению паролей с помощью специальных программ. Одна база с такой защитой хорошо попортила мне нестроение. Теперь я попорчу настроение её авторам рассказав об этой защите. Способ основан на том, что пароль БД формата Access 2000 и 2002−2003 — текстовая строка в формате Unicode. При этом, нет ни каких ограничений на её содержимое. Стандартный способ установки и использования пароля БД подразумевает его ввод с клавиатуры в диалоговом окне. Если стока пароля содержит непечатные символы, то они не будут корректно отображены программой открывающей пароли БД. С другой стороны этот пароль нельзя ввести в диалоговом окне при открытии БД в MS Access.

Но и про Access 97 я не забыл. Дело в том, что в спецификации баз данных и в справке по DAO 3. 60 указано, что максимальное число символов в пароле — 14. Но на самом деле их может быть 20. При этом и сам Access 97 не допускает ввода строк пароля более 14 символов. В спецификации Access 2003 также сказано про 14 символов, но программа допускает ввод всех 20. Также возможно использование непечатных символов, что приводит большинство программ взламывающих пароли в ступор.

Для установки такого пароля потребуется использовать программу, использующую метод CompactDatabase библиотек ADOX или DAO.

Список литературы

реляционный база телефонный станция

1. Карпова Т. С. Базы данных: модели, разработка, реализация. — СПб. :Питер, 2010.

2. Фуфаев Э. В. Базы данных. Учебное пособие для студентов учреждений СПО, 5-ое изд. — М.: Издательский центр «Академия», 2008.

3. Кузин А. В., Демин В. М. Разработка БД в системе MS Access: учебник, 3-е изд. — М.: Форум, 2009.

4. Дунаев В. В. Базы данных. Язык SQL для студента: 2-е изд. доп. и перераб. — Спб.: БХВ-Петербург, 2012.

ПоказатьСвернуть
Заполнить форму текущей работой