Сохранение электронных таблиц

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

— имени накопителя информации (имени накопителя на гиб­ких магнитных дисках, имени логического устройства в рамках накопителя на жестких магнитных дисках, имени другого нако­пителя);

— имени каталога или папки файловой системы выбранного на­копителя информации;

— имени файла, в котором сохраняется электронная таблица (точнее книга или блокнот, в состав которого включена сохраняе­мая таблица);

— формата сохранения (документ данного табличного процес­сора, документ более ранних версий того же табличного процессо­ра, документ другого табличного процессора, текстовый документ, документ формата базы данных, другие стандартизированные форматы обмена информацией);

— условий последующего доступа (пароля при открытии фай­ла, режим внесения изменений).

Глава 11

 

СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ

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

 

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

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

— собираемые, хранимые и обрабатываемые данные относятся к определенной и ограниченной области деятельности, характер­ной для людей, их использующих, и называемой предметной об­ластью',

— сами данные разбиты на определенные компоненты, различ­ным образом связанные друг с другом, т. е. они структурированы и упорядочены;

— имеются определенные методы поиска и извлечения (вы­борки) необходимой информации и ее представления.

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

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

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

Рассмотрим пример. Данные о сотрудниках некоторой проект­ной организации включают в себя:

— табельный номер сотрудника;

— фамилию, имя и отчество;

— дату рождения;

— домашний адрес;

— домашний телефон;

— дату поступления на работу;

— место работы;

— служебный телефон;

— должность;

— оклад;

— надбавку за стаж работы;

— проект, в котором участвует сотрудник;

— надбавку за участие в проекте.

Эти данные можно представить в виде таблицы, в которой каж­дому виду данных соответствует свой столбец, а каждому конкрет­ному сотруднику — строка (табл. 11.1).

Каждая строка этой таблицы (отношения) называется записью, а ее отдельный элемент, соответствующий тому или иному столб­цу, — полем.

Таблица 11.1 представляет собой лишь небольшой фрагмент БД, но его свойства весьма показательны.

Во-первых, некоторые поля являются достаточно сложными и содержат данные, которые можно (и нужно) разбить на более мел­кие компоненты (это поля, содержащие фамилию, имя и отчество, даты, адрес, место работы).

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

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

Для исключения хранения излишней информации из табл. 11.1 необходимо убрать поля, касающиеся свойств объектов, отличных от персонала, и создать для них свои отношения: «Отдел» (табл! 11.3) и «Проект» (табл. 11.4), «Надбавки» (табл. 11.5). Тогда отношение «Персонал» будет описано табл. 11.2.

Описанные действия по представлению данных в теории и практике создания БД называют нормализацией.

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

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

Представленные в табл. 11.2—11.5 отношения связаны друг с другом через отдельные поля: отношения «Персонал» и «Отдел» — через поле «Номер отдела» (соответственно вторичный и первич­ный ключи); отношения «Персонал» и «Проект» — через поле «На­звание проекта» (соответственно вторичный и первичный ключи). Связь отношений «Персонал» и «Надбавки» осуществляется через поля «Дата поступления на работу» (составной вторичный ключ) и «Стаж работы» (первичный ключ), но не непосредственно, а через процедуру вычисления стажа работы по значению даты поступле­ния на работу.

Представленное в описанном примере структурирование и упо­рядочивание данных в целом характерно для всех систем управ­ления БД и для различных программ отличается в деталях.

Сведения о персонале проектной организации

Табельный номер

Фамилия, имя, отчество

Дата рождения

Домашний адрес

Домашний телефон

Дата поступле­ния на работу

Место работы

Служебный телефон

Должность

Оклад, руб.

Надбавка за стаж работы, %

Проект

Надбавка за участие в проекте, %

Соловьев Георгий Иванович

13 июня 1955 г.

Москва, Веш­няковская ул., 13, кв. 54

1 сентября 1975 г.

17 отдел, к. 29

Конст­руктор

Башня

Николаев Сергей Алексеевич

15 января 1960 г.

Московская обл., г. Люберцы, Шосейная ул., 5, кв. 42

12 июня 1984 г.

15 отдел, к. 32

Инженер

Мост

Архипова Валентина Сергеевна

1'7 марта 1970 г.

Москва, Волго­градский просп., 78, кв. 32

10 октября 1993 г.

15 отдел, к. 32

Техник

Башня

Державин Михаил Петрович

30 мая 1960 г.

Москва, Ферганская ул., 16, кв. 4

23 августа 1987 г.

17 отдел, к. 29

Конст­руктор

Мост

Иванова Елена Михайловна

23 января 1975 г.

Московская обл., г. Мытищи, Центральная ул., 14, кв. 7

7 февраля 1996 г.

17 отдел, к. 29

Лаборант

Мост

Егоров Александр Тихонович

18 декабря 1952 г.

Москва, Ленинский просп., 43, кв. 109

11 августа 1972 г.

15 отдел, к. 32

Технолог

Мост

Карпов Евгений Анатольевич

27 октября 1969 г.

Москва, 2-я Хуторская ул., 11, кв. 187

15 января 1985 г.

15 отдел, к. 32

Инженер

Башня

 

 

Таблица 11.2

Отношение «Персонал»

Табельный №

Фамилия

Имя

Отчество

Дата рождения

Место жительства

Домашний телефон

Дата поступления на работу

Номер отдела

Должность

Оклад

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

День

Месяц

Год

Регион

Адрес

День

Месяц

Год

 

 

Таблица 11.3 Отношение «Отдел» Номер отдела Расположение отдела (номер помещения) Телефон	Таблица 11.4 Отношение «Проект» Название проекта Надбавка за участие в проекте
Таблица 11.5 Отношение «Надбавки» Стаж работы Надбавка за стаж работы