База данных в AppleWorks – на 99 процентов аналогична QuickFile, разработке того же автора. Отличия от QuickFile – база данных в AppleWorks намного быстрее и компактнее.
С этого места в тексте и до его конца, AppleWorks обозначает “AppleWorks для Apple II”. Зачем это приходится уточнять, смотрите в начале серии.
Начало погружения в AppleWorks здесь.
В меню “Другие действия” 7 позиций:
Первая и шестая команда связаны общностью темы, расскажу сразу об обеих.
При запуске программы ей необходимо было указать место в файловой системе, где она могла бы размещать собственные файлы, куда сохранять файлы с рабочего стола и для всяких других нужд. Это место называлось “стандартной директорией”, путь к этому месту сохранялся после выхода из программы (даже нештатного).
В процессе работы, для нужд текущего момента, пользователь мог выбирать место (диск и путь к файлу) для сохранения собственных файлов и для других нужд – это называлось “текущим диском и путем к файлам”. Эта настройка при выходе из программы забывалась.
Первая и шестая команды соответственно изменяли “текущее место” и “стандартное место” расположения файлов.
Вторая команда выводит список файлов на “текущем” диске. На 5,25-дюймовой дискете в формате ProDOS файлов могло быть до 51, на случай, если их больше, чем умещается на одной странице, была предусмотрена операция “More”.
Третья команда создает поддиректории. В ProDOS иерархическая файловая система, с неограниченным уровнем вложения. На Mac’ах в это время настоящих директорий еще не было.
Четвертая команда понятна без пояснений.
И с форматированием дискет все понятно, хотя многие из моих читателей никогда этого не делали. К этой операции прибегали, например, в случаях, если диск был отформатирован в DOS 3.3. С точки зрения ProDOS и AppleWorks такие дискеты были “пустыми”.
С настройкой принтеров тоже все понятно: это очень много всевозможных параметров, некоторых из которых в наши дни не хватает.
То, что в AppleWorks называлось базой данных, в наши дни больше похоже на таблицу в реляционной базе данных. Настоящую СУБД в тогдашний персональный компьютер, даже в самый большой и продвинутый по тогдашним меркам, впихнуть было невозможно.
Рекомендуемый объем оперативной памяти для AppleWorks – 128 килобайт, но программа устойчиво работала и при 64. Только памяти немного не хватало.
База данных AppleWorks и в самом деле похожа на фрагмент электронной таблицы. Те же “столбцы”, те же “строки” и “ячейки”. Только строки в ней называются записями, столбцы (в сегодняшних БД “поля”) – категориями.
Apple IIe и Apple IIc – 8-битные компьютеры. Возможности тех, кто писал программы для них, были ограничены со всех сторон. Впрочем, самые ценные шедевры живописи были созданы в те годы, когда художникам, чуть ли не под страхом смерти, запрещалось живописать что-либо, кроме библейских сцен и героев. Они и изливали в этих сценах и героях всю боль и все надежды души, вкладывая в каждое движение кистью целый мир.
Программисты тех лет создавали настоящие шедевры, иначе было никак – но возможности этих шедевров были ограничены архитектурой.
При любом объеме оперативной памяти, в базе данных AppleWorks записей могло быть не больше 1350. В реальности все было печальнее: при 64 К оперативной памяти их число не могло превышать 140, при 128 К – 750.
Другие ограничения не зависели от объема оперативной памяти:
Внешне база данных в AppleWorks – этой файл типа “Data Base”. В нем хранились её структура, значения всех её записей, настройки форм и отчетов и некоторые другие данные.
Все, что можно делать с БД, сводится к двум группам операций: “Просмотр/Добавление/Изменение” и “Отчеты”.
Независимо от того, что хранилось в базе и для чего она использовалась, внешне это был самый обычный файл. Файл типа “Data Base”.
Как и любой другой файл в AppleWorks, чтобы его просматривать, что-то в него добавлять или менять в нем, сначала нужно было его создать. За эту важную миссию отвечает первая команда в Главном меню. Файл базы данных либо создается с нуля, либо импортируется из внешнего мира – поддерживается несколько “чужих” форматов.
Импорт осложняло одно обстоятельство: AppleWorks работала с носителями информации только в формате ProDOS. Чтение представленного на “неправильных” носителях было не то чтобы невозможным (программ для этого было в достатке), но отнимало время, которое самый невосполнимый ресурс в мире. Зато для AppleWorks не было особой разницы между носителями для DOS 3.3 и для MS DOS.
При создании базы данных с нуля пользователь должен был определить его структуру.
Интерфейс, в котором у пользователя нет возможности спонтанно менять ход событий, не так плох, как это кажется. Как будто кто-то мудрый и знающий ведет за собой, не давая отвлечься. Очень похоже на Wizard’ы или Guide’ы в Windows и Mac OS.
Сначала нужно обозвать файл базы данных. Альтернатива – прекратить создание файла. В имени файла разрешалось использовать только буквы латинского алфавита, цифры, точки и пробелы. Имя файла не могло начинаться с цифры и состоять более чем из 15 символов.
Затем AppleWork требовала определить и назвать категории. Первую она создавала без указаний со стороны пользователя, поскольку в любой базе данных должна быть хотя бы одна категория. Новорожденная первая категория называлась Category 1. Изменить её можно было на что угодно (латиница, пробелы или цифры, не длиннее 20 символов, цифра в начале имени недопустима) и как угодно. Руководство рекомендовало включить режим замены (Overstrike, в других ОС Overtype) командой Apple-E и запечатать врожденное имя своим. Утвердить имя нажатием Return.
При этом создается новая категория, Category N, где N – её порядковый номер. Забить, нажать Return – и так до конца. Утвердив последнюю категорию новой базы данных, надо было нажать Escape. Категория, созданная после последнего Return, самоуничтожалась, а база данных была готова принимать данные.
AppleWorks была очень либеральна. Даже если в базе данных уже были записи, можно было не только переименовывать имена категорий, но и добавлять новые, удалять те, что уже есть, переставлять их.
Была у базы данных AppleWorks особенность, способная жестоко наказать того, кто считал себя умнее всех и не читал документацию. Если в имени категории было сочетание букв “date” или “time”, значения этих категорий конвертировались в представление даты или времени в стандарте AppleWorks. Если конвертировать значение было невозможно, программа начинала противно пищать об ошибке, не разрешая продолжать ввод данных.
Для любого числа категорий можно было задать значения по умолчанию. В любой момент эту настройку можно было изменить или отменить.
Если значение категории в создаваемой записи такое же, как в предыдущей, вводить его было необязательно, достаточно было ввести Apple-“. Кавычку.
А убить файл базы данных было, как и в случае с человеками, намного проще, чем просто: файл нужно было удалить с рабочего стола (если он был в него включен) и удалить на диске. И все.
Слово “формы” может ввести в заблуждение. В AppleWorks это всего лишь способы представления записей базы данных на экране, и их только две. Single-Record и Multiple-Record. Форма для показа одной записи и для показа их в табличном формате, сколько только сможет уместиться на небольшом экране.
Для переключения между формами используется команда Apple-Z, то есть “увеличить”. Если на экране “уменьшенный” показ записей, в виде таблицы, Apple-Z развернет запись в “увеличенную” форму, если наоборот – то наоборот.
В Multiple-Record можно отбирать категории для показа на экране. Больше чем 4 или 5 категорий просто не уместились бы. Естественно, данные в записях от этого никак не страдают, и в любой момент форму можно перенастроить на показ тех же данных по-другому.
О том, как вводились и редактировались данные, скажу только одно: удобно и красиво, хоть и без лишней спонтанности.
База данных – это место, где хранятся данные. Но главное её предназначение в другом: в извлечении из огромных массивов информации той, которая отвечает каким-то критериям.
В базе данных AppleWorks не поддерживался SQL, но можно было изменить правило отбора записей (для показа на экране). Для изменения правила отбора записей достаточно было ввести Apple-R, и вместо правила “All records”, то есть “показывать всё”, задать свое собственное.
Выбрать категорию в качестве критерия отбора, выбрать из предлагаемого списка тип сравнения, и если сравнение не было “Is blank” или “Is not blank”, указать значение для сравнения. Для включения нового правила достаточно было нажать Escape.
В правиле отбора можно было задать до трех выражений, соединенных логическими операторами И и ИЛИ.
Вернуться к показу всего или поменять критерий было ничуть не сложнее: Apple-R и либо включаем “All records”, либо редактируем существующие критерии отбора, либо создаем новые.
Кроме Apple-R был еще и Apple-F, искавший сочетания букв во всех категориях всех записей.
Записи можно было расположить в определенном порядке. Руперт использует для этого термин “arrange”, вообще это “sort”, то есть “отсортировать”. Предопределенные порядки сортировки: A->Z, Z->A, 0->9 и 9->0. Просто, понятно, подходит почти для всех случаев жизни. Кроме того, сортировать записи можно было по временным значениям, в прямой и обратной хронологической последовательности.
Управление сортировкой включалось Apple-A. Может, из-за этого и используется термин Arrange, так как комбинация Apple-S уже занята командой Save.
Самое важное искусство для нас – это красиво составленный отчет. Это сразу и кино, и цирк, и все прочие прелести цивилизации.
Отчеты в AppleWorks были двух базовых типов: “табличные” и “с названиями категорий”, то есть вариациями на тему Single-Record и Multiple-Record форм. Только в отчетах обеими этими способами выводились все записи, согласно включенному правилу отбора.
В файле базы данных могло храниться до 8 настроек отчетов. В настройках задавалось, какие из категорий и в какой последовательности выводятся для каждой записи, используются ли заголовки для категорий и как именно они называются в отчете.
В наши дни все намного изощреннее, но продукция AppleWorks вполне профессиональна даже по сегодняшним меркам.
В отчетах можно было создавать вычисляемые категории. До 3 таких полей.
Для использования в вычислениях имена категорий не подходили. Поэтому с первыми 26 категориями в базе данных связывались буквы латинского алфавита. Первая (по счету) была A, вторая B – и так далее.
В вычисляемой категории хранилась формула, например A x 0.05 + A, или 1.05 х A.
Категорий могло быть 30, букв в латинском алфавите 26. Как быть с категориями с 27-й по 30-ю? А никак. Они не могли использоваться в вычислениях. Если же категорию номер 28 (например) надо было кровь из носа в них использовать, ничем кроме её переноса на одну из первых 26 позиций помочь ситуации было невозможно. После этого рекомендовалось проверить все формулы во всех отчетах.
Кроме того, были функции группировки значений и вычисления итоговых сумм, но это куда тривиальнее.
ePN © 2023 Все права защищены.